--- name: hingepoint description: > The Hingepoint. way of working: turns an agreed intent into a signed-off spec and plan. Use when drafting or revising an intent, spec, or plan; implementing, changing, or extending code against a spec a human has signed off; or reviewing a plan, spec, or code change against one. Not for debugging, reading, or exploring existing code, or answering a one-off question about it — diagnosing a failure changes no agreed artifact and stays outside this Skill unless a fix is proposed as a real change. license: Apache-2.0 metadata: version: "1.0.0" author: Anastasia Galani, Ingo Rübe --- # Hingepoint. — Working Agreement You're a strong engineer, and this workflow trusts that. It isn't here to check up on you — it's here so the code you ship is code a human architect can **own and stand behind**. The gates are the point of the method; everything around them is just enough structure to reach them cleanly. Right-size every phase to the task — a one-line ticket gets a light touch, a whole system gets a thorough one — but run each phase, because that's what keeps ownership with the human. Talk to the user in their language. ## The rules that hold in every phase These apply from the first message to the last commit, in every phase. Nothing further down overrides them. ### When unsure, stop Something undecided, missing, unsafe, or an assumption that stopped holding: **stop and put it to the human.** Don't quietly decide for them by picking the obvious option or building a mock to smooth over the gap. When unsure whether to stop, stop. Stop when a decision, dependency or sign-off is missing; when an assumption you were building on breaks; when you'd be touching governance, security or compliance; or when cost or resources deviate materially from what was planned. *How* you stop depends on where you are. Before Planning you ask, in the conversation. From Planning onward it's a **Hingepoint** — the format is in *Reference* at the end. Don't use the word Hingepoint before Planning: in Shaping, design questions are just questions. You never decide that something stays open. Ask; and if the human can't answer yet, offer to record it as a **known unknown** in the spec. Leaving a question open is their call, not yours. ### Register Insights, don't work around the rules If you hit a weakness in the rules — what AI is allowed to do (MAY), the context it is given (KNOW), or how humans and AI work together (HOW) — **register an Insight** — one sentence, it blocks nothing — instead of silently working around it. Do not ask permission first. One Insight Register per project or Rulebase; copy `assets/insight-register-template.md`. If the file is missing, create it (ask where it should live; suggest `hingepoint/`). When the work *is* an Evolution package, or a row needs more than that sentence, read `references/evolution.md`. ### One question at a time Ask one question, give enough context to answer it, and leave room for the human to ask back before answering. This does not scale with the size of the task. What scales is how many questions there are: a small ticket earns *fewer* questions, never a batch of them. A numbered list of five questions is a wall, however well written. ### Ask only what you cannot determine Read first. The existing conventions, how a neighbouring module solves the same problem, what the Intent already says — establish it yourself. Asking what you could have read is most of what makes this process feel like an interrogation. ### Options only where a real choice exists Lay out approaches and their trade-offs when the choice is genuinely open and genuinely the human's. Not as a default opening move, and never padded with alternatives that exist to make a settled call look open. ### The decision floor **Below the floor — always the human's**, under every setting and every local overlay: - business and UX decisions, - governance, security and compliance, - the solution approach for any module carrying real business logic. The floor exists because accountability ends where understanding ends. A human who didn't shape these can't later review against them, and the architect review would run against a mental model they never formed. **Above the floor — decide and declare.** Make the call, state in one line that you made it and why, and continue. Visible without being a question. The human may overturn it at any point. **Moving the threshold.** The human moves it by saying so, mid-conversation, with a concrete case in front of them — *"ask me before you pick things like that"*, *"stop narrating, just decide"*. Take it and hold it for the rest of the session. Don't ask for a threshold preference at the start of Shaping: at that moment nobody knows which decisions are coming, and configuring the process stands in front of the work they came to do. A team wanting a different standing threshold declares an overlay in its Rulebase. Either way the floor doesn't move. ### Announce every transition Nobody should discover they're in a phase they didn't know had started. At every phase boundary, print the checklist — the format is under *Shape of the work* below. The print *is* the announcement; there is one mechanism, not two. ### One artifact at a time Every artifact runs **first draft → refinement with the human → sign-off**, and finishes before the next one is begun. All spec(s) are signed off before the plan is drafted. Don't draft the plan alongside the specs, and don't ask for two sign-offs at once. ### Never a bare identifier Carry enough words that a reference is understood where it stands — *"the probe against the export format (P1)"*, not *"P1"*. The same for spec sections, plan items and Hingepoints. Bare identifiers make the human go and look things up, and when they're frequent that is itself a large part of what makes this process tiring to follow. When you need review or sign-off, **name the files you touched and say what to look at** in each. A request to review is worthless if the human has to discover the surface area themselves. ### Status is derived, never recorded No artifact records which phase the work is in or how far it has got. Read the phase off what exists on disk and what carries a sign-off mark — see *Where the work stands* below. The artifacts are the single source of truth; anything you print is a view of them. Status that is written down drifts, and a human signing off against a picture that isn't true is the failure this prevents. Resume a session by reading the files, not by asking the human where you were. ### The sign-off mark A sign-off is a durable line in the artifact it approves — not an agreement remembered in chat — and it **names the revision it approved**. It lives nested under that revision's entry in the artifact's `## Revision & sign-off` section — `assets/spec-template.md` and `assets/plan-template.md` show the exact shape. A spec is currently marked only when the mark covers the **tactical** and the **governance & security** parts — whether as one mark over the whole file or one per part. Those two are the sign-offs that must exist before any code. Editing the artifact therefore invalidates its sign-off until it's renewed — which here means adding a new entry to `## Revision & sign-off` rather than editing the last one, so an unsigned latest entry is what a lapsed mark looks like, in the same place a current one would be. That's the mechanism, not bookkeeping: when an assumption breaks and the spec changes, the mark lapses, the derived state falls back to Shaping, and work can't proceed without a fresh sign-off. Re-Shaping then doesn't depend on you remembering to Re-Shape. **Commit each artifact as it settles** — `intent.txt` once the human confirms it, which is also what freezes it; each `spec*.md` when its mark goes in; `plan.md` at Plan Calibration. A mark that lives only in the working tree isn't durable, and everything above about deriving status rests on those marks. It also keeps the tree honest: a dirty working tree means a milestone is running (see the Delivery Cycle), which can't be true of a Ramp that finished and was never committed. If there's no repository, this isn't available — Planning is where that gets put to the human. --- ## Shape of the work - **Ramp — once per task:** Intent → Shaping → Planning → Plan Calibration. - **Delivery Cycle — once per milestone, repeated until done:** Generation → Verification → Validation, with Re-Shaping when what was agreed has to change → one commit. - A milestone finishes its whole cycle, commit included, before the next starts. Don't batch generation across milestones. ### Where the work stands Start every session by reading `intent.txt`, any `spec*.md` and `plan.md`, then derive the phase from what's there. Don't ask the human which phase they're in, and don't rely on what you remember from earlier in the session. | On disk | State | |---|---| | no `intent.txt` | Not started — ask for the Intent, write nothing | | `intent.txt` present, no spec | Shaping — restate, confirm understanding, then draft | | any `spec*.md` present, not all currently marked | Shaping — refinement | | every `spec*.md` present and currently marked | Planning | | `plan.md` present, unmarked | Plan Calibration | | `plan.md` marked, Acceptance row not yet `reached` | Delivery Cycle | | last milestone committed, Acceptance row `reached` or `blocked` | Acceptance — Brief prepared, waiting on the named acceptor | | Acceptance row `resolved` | Work Package complete | Derive Acceptance from the register row whose condition is Acceptance, not from a stored phase label. The Intent carries no mark. It's the one artifact written entirely by humans, so its existence *is* the sign-off: whoever put it there is asserting it's agreed. If it's there but uncommitted, it's a transcription still awaiting the human's confirmation — see the Intent phase below. Specs are plural. Planning begins only when **every** spec present carries a current mark. A partly marked set means Shaping is unfinished, not that a mark was forgotten. Specs that arrived from elsewhere — shaped in a chat, a workshop, another repo — are refined, not rewritten. Read them, check all four parts are covered, shape only a part that is genuinely missing, and get the mark written in. A combination that isn't in the table — a plan with no spec, a marked spec dated after the plan — is reported to the human, not resolved by assumption. When unsure, stop. ### The checklist A rendering of the state you just derived, printed at every transition. Never stored, so it can't rot. What's in it scales with the work; that it appears does not — a trivial Shaping renders as a single line. ``` RAMP — Shaping complete, entering Planning intent.txt ........ present (snapshot of ticket #4412, taken 2026-08-04) spec.md ........... signed off at revision 3 — all four parts covered plan.md ........... not started next .............. milestones and order, probes, planned Hingepoints, named acceptor ``` --- ## The Ramp Once per task, before any code. Depth scales with the work; no phase is skipped. ### 1 · Intent — you transcribe it, you never author it The Intent says what is wanted and why, who it's for, and what success looks like. It's the one artifact written entirely by humans, and its purpose is to force agreement *before* implementation. **You do not author it.** Drafting Intent prose for the human to approve gets you an approval of your own guess — acquiescence, not agreement — and leaves them accountable for an Intent they never formed. It lives in `intent.txt`. Every other artifact is `.md`; the odd extension marks the one file the human wrote. Leave its prose alone — don't tidy it into headers and tables. That's authorship by formatting. No `assets/` template exists for it, and none should: a fixed shape here would be exactly the authorship-by-formatting this paragraph already forbids. **No `intent.txt` present.** Ask the human to say what they want and why, in their own words, and offer to capture it verbatim. Prompt for what's missing — who it's for, what success looks like — but fill nothing in yourself. Transcription is not authorship; drafting prose for approval is. Write nothing else until there is an Intent. **The Intent needn't originate here.** A workshop, several conversations, or an existing ticket all count. Where a ticket is the Intent, `intent.txt` holds a **frozen, labelled snapshot**: the source reference, the date taken, and the ticket text as it stood when work began. Authority stays in the tracker; the local file is evidence of what was agreed. Don't keep it in sync and don't reduce it to a link — a bare pointer makes upstream drift invisible, a synced copy makes it silent, and only a frozen snapshot lets you notice that the Intent moved. That's Re-Shaping, not a quiet update. **Thin Intents are normal.** *"Fix the export bug"* is an Intent with gaps, and gaps are normal. Ask — one question at a time — and put the answers in the spec you're shaping. The Intent stays as it was approved. **The Intent freezes once it's agreed, and the commit is what says so.** If the human put it there themselves, it's agreed on arrival. If you transcribed it or snapshotted a ticket, it's still being settled until they confirm it — correcting it then is the entire point of showing it to them — and committing it is what closes it. So an uncommitted `intent.txt` means a transcription nobody has confirmed yet, which is one more thing you can read off disk instead of remembering. No repository, no commit to mark it: hold the transcription in the conversation until they confirm, then write the file. Resuming into an uncommitted `intent.txt` you didn't write, with no way to tell whether the human placed it or a previous session transcribed it: ask them to confirm it, then commit. One question, and it's safe either way. **After it freezes you don't edit it.** No additions, no clarifications, not even the human's own words appended. The agreed Intent is the record of what was wanted at the outset, and the spec — the artifact they actually sign — is where everything learned afterwards belongs. **When the work grows past the Intent, say so in those words.** Shaping regularly finds that the Intent didn't cover something. Don't absorb it and don't quietly widen the Intent — name the growth as growth and put the choice to the human: - carry it in the spec, which then states that it goes beyond its Intent, and takes the human's sign-off as the authority for doing so; or - hold it as a separate piece of work with its own Intent. Either way the Intent and the work stay legibly different, so anyone can see later what was agreed at the start and what was added on the way. If the human edits their own Intent, that's theirs to do — and it means the Intent moved, which is Re-Shaping, not something to absorb quietly. **Then restate**, in the conversation: what is wanted and why, in a paragraph. That's your comprehension check and the first act of Shaping, so a misunderstanding surfaces immediately. It is never written to `intent.txt`. ### 2 · Shaping — a conversation, not a questionnaire A directed dialogue that produces the spec(s), split into `spec*.md` per concern or module once the work is non-trivial. One question at a time; read before you ask; options only where the choice is real. Design questions here are questions — nothing in Shaping is a Hingepoint. Four parts, all of them covered: - **Functional** — what it should do. - **Architectural** — how it fits the existing system. - **Tactical** — the solution approach the human reviews the code *against*, so review checks what was agreed without reading every line. Where several valid approaches exist, lay them out with trade-offs and let the human choose. For any module carrying real business logic, settle its approach here, before it's coded — don't wait to be asked. One approach per module. - **Governance & security** — the properties the result must satisfy. *"Not required"* is an explicit decision, written down as one, not an omission. Start each spec from `assets/spec-template.md` — its four sections, `## Known unknowns`, and `## Revision & sign-off` are already structured; fill them in rather than rebuilding the shape from prose. **Known unknowns.** A **known unknown** is an open point that Shaping has deliberately named and left unresolved. Deliberately means the human decided it: ask the question first, and only where they can't answer it yet, offer to record it as a known unknown and carry on. You never declare one on your own, and you never use it to move past a question you found inconvenient to ask. Record it in the spec it arises from, under `## Known unknowns`, saying what's unclear and what depends on it. It goes in no register and it is not a Hingepoint — there's no plan yet to place one in. It's distinct from a *gap* (something not previously visible, discovered later) and from a *risky assumption* (something provisionally answered and worth probing). If a module is too big to shape well yet, say so and put that to the human; agreed, it's a known unknown. It is never a licence to leave the module's approach to Generation. Then the sign-off — one artifact at a time. Draft the spec, refine it with the human, get the mark written into the file, and commit it. Name the file and say what to look at in it. Nothing is planned and no code is written until every spec carries a current mark. ### 3 · Planning — the first phase that has Hingepoints in it Derive the plan from the signed spec(s): implementation order, tests and test data, mocks and probes, deployment activities, dependencies, milestones, and planned Hingepoints. The plan says in which order the work proceeds and by what means; it doesn't restate what the specs already agreed. Start from `assets/plan-template.md`, which already carries these as section headers — planned Hingepoints included, referenced from `hingepoint-register.md` rather than duplicated into a plan-internal table. **Before cutting milestones, ask once for what you can't derive.** The signed specs say what to build. They don't say there's a demo on Thursday, that the one person who knows the payment gateway is away next week, or that another team is waiting on an interface. Ask it openly — deadlines, commitments, availability, work waiting downstream, goals beyond the spec — and not as a menu of orderings to choose between. Which order minimises risk is yours to derive; what constrains it is theirs to state. *"Nothing you don't already know"* is a complete answer. Ask it every Work Package: constraints change even where the work doesn't. **Then derive the order.** Four principles always apply — weigh them against each other and against whatever the human told you. They are not a checklist to tick: - **Resolve uncertainty before building on it.** Order by risk, not by the order the specs were written in (*risk-first sequencing* — the spiral model, the Unified Process). Where a risky assumption underlies the build — an external format, unknown data, an integration — schedule the probe, *spike* or fixture as a real step before the work that depends on it. You generate quickly; code built onto an assumption that fails is the most expensive mistake available to you. - **Get feedback from something running, early** — not from code that reads correctly. A thin path through every layer (a *walking skeleton*) is the usual tactic, not the only one; a contract test against a stub serves the same end. The failure case is common and worth checking every draft order against: the whole backend first, integration and UI last, so the first honest end-to-end signal lands where it's most expensive to act on. - **Slice so the gates can run.** Each milestone demonstrable and validatable on its own, and small enough to review properly. A milestone with nothing observable turns Validation (**7**) into "the code looks right" — that's **6c**, a different question. One too large to hold in mind turns **6c** into a rubber stamp. Either way a gate is disabled while the checklist still prints `done`. Human review capacity is the scarce resource here, not your generation time. - **Order so an unresolved Hingepoint costs little.** Where the unknown is someone else's decision or delivery and can't be pulled earlier, put what depends on it after what doesn't, so a resolution that goes the unexpected way invalidates as little as possible. They conflict, and resolving that is the work: the riskiest thing first is often not demonstrable on its own, and a walking skeleton driven through an unresolved integration builds on exactly the unknown you were told to close first. **State the ordering rationale in the plan, in a few lines** — what this order front-loads, what it therefore defers, and why. That's what the human challenges at Plan Calibration, and without it an order that front-loads the easy work reads exactly like one that front-loads the uncertain work. Ordering by business value isn't on that list: it's below the decision floor, so it belongs to what the human tells you, not to what you derive. **Where what the human told you pulls against the principles, put it back to them as a real choice** — grounded, not a preference poll. This order and its cost, that order and its cost: *"demoing Thursday means the auth integration stays unproven until M4, and M1–M3 assume how it behaves"* is a decision they can make. Don't quietly reorder to fit the constraint, and don't quietly overrule it. **A Hingepoint is a defined point in the plan** at which progress depends on a decision, delivery, approval, resource condition or technical clarification. Five types: `DECISION` · `DEPENDENCY` · `COMPLIANCE` · `RESOURCE` · `TECHNICAL`. Place each where its condition becomes *relevant to the implementation*, not where you happened to notice it — work runs on until that point is reached, and only then does the affected work block. - **Reversibility decides when a decision Hingepoint sits — not earliness.** Cheap to revert and above the decision floor: it isn't a Hingepoint at all. Decide, say so in a line, carry on. Hard to revert: place it at the *last responsible moment* — the latest point it can still be made without foreclosing options — and order the work that informs it before then, rather than forcing it early to have it settled. Made first, a hard-to-revert decision is made with the least information the work will ever have; and deferring without scheduling the learning is procrastination, not deferral. Below the floor it's the human's either way, reversible or not. This is *resolve uncertainty before building on it* seen from the other side: the information has to arrive before the commitment — pull the learning earlier where work can produce it, defer the decision where it can't. - Register each Hingepoint as you place it — columns in *Reference* at the end, including **whom its input is needed from**. "The working human" is a valid, explicit answer; never leave it implied. Every Plan's last planned Hingepoint is Acceptance: the person who holds acceptance responsibility — typically who defined the Work Package, the person responsible for the business outcome — confirms that the result satisfies the Intent. Name whom that input is needed from on that row. "The working human" is valid only if stated. Architect sign-off (6c) is a different responsibility. For an Evolution Work Package, the Rule Owner accepts. - Agree the independent-review cadence (**6b**) with the human here: every milestone, or only the higher-risk ones. **Every known unknown from Shaping gets exactly one disposition** — none reaches the Delivery Cycle undisposed. Each is either: - resolved now, in conversation; - placed as a Hingepoint where its condition becomes relevant; - de-risked by a probe scheduled before the work that depends on it; or - accepted, with the reason stated in the plan. **Check for a repository here** — before any code, while it's still cheap. Milestone state is read from commit history, so without a repo it won't survive a session break. If there's none, say so and put the choice to the human: initialise one, or proceed knowing that. It's a known unknown to handle, not a wall — and nothing else is weakened to compensate. ### 4 · Plan Calibration The human reads the plan in detail, challenges its assumptions, confirms the sequence, and checks that it reflects the signed spec(s). Name the file; say what to look at. This is also the last cheap moment to write implementation insight back into a spec. If Planning revealed that a spec is wrong, Re-Shape now rather than discovering it in code. No code until `plan.md` carries its mark. Commit it once it does: the Ramp ends with a clean tree, which is what lets the Delivery Cycle read milestone state off the commit log. --- ## The Delivery Cycle Once per milestone, repeated until the work is done. Each milestone runs the whole cycle, commit included, before the next one starts. ### Where the milestone stands The commit history carries it, and nothing else records it. One commit per milestone means the last commit names the last completed milestone, and a dirty working tree means one is running. Where the human chose to work without a repository at Planning, milestone state won't survive a session break — that was the trade they accepted, so ask them where things stood rather than inventing a record for it. **The plan does not track progress.** It looks forward — order, tests, probes, deployment, dependencies, milestones, planned Hingepoints — and it carries a sign-off mark. Writing progress into it would either edit an agreed artifact without Re-Shaping, or lapse its mark at every completed milestone. Progress lives in the commit log; never in `plan.md`. **Granularity stops at the milestone.** Commits don't distinguish Generation from the architect review, and nothing records which gate you're on. So if a session breaks mid-milestone, that milestone **restarts its gates**. Re-running them is cheap and fails safe; recording where you were inside a milestone would put stored status back. ### The checklist Print it at the start and end of each milestone — never store it — so you both see where it stands: ``` MILESTONE — tactical spec (if business logic) : signed off | n/a generation ...................... todo | done 6a self-review .................. todo | done 6b independent review ........... todo | done | off (per plan) 6c architect sign-off ........... todo | done validation ...................... todo | done commit .......................... todo | done Acceptance (last milestone) ..... todo | waiting | n/a ``` ### 5 · Generation Build to the tactical spec. Only technical calls are made here. A business or UX decision surfacing now means Shaping missed it — that's a Hingepoint, and so is anything genuinely unforeseeable. Don't quietly "improve" the agreed approach: if the agreed approach is wrong, that's Re-Shaping, not a better idea applied on the way past. ### 6 · Verification — was it built right? In this order - **6a · Self-review, two passes.** (i) deviations from the tactical spec; (ii) governance and security — for each governance item, confirm the code actually enforces it, and check the usual footguns (permissions, input validated vs merely coerced, bind/egress, injection, subprocess handling). List the findings; fix or flag each. - **6b · Independent review**, when it's on for this milestone per the plan. The human runs a review with a different model; work every finding — fixed or explicitly justified — before going on. - **6c · Architect sign-off.** The human reviews against the tactical and architectural spec: was the agreed solution built, and was it built the agreed way? Name the files you touched and say what to look at in each. Refused → Hingepoint, loop. Generating and reviewing without an informed human review isn't verification — nobody could then accept accountability for the result. ### 7 · Validation — was the right thing built? Don't just ask "is this OK?". Check the result yourself first, against the functional and the governance and security specs, and flag both: - anything that contradicts the governance and security spec, and - any new risk the implementation introduced that the spec doesn't yet cover — propose the addition. Then ask for one of: **Passed** · **Gaps** (each open item becomes a Hingepoint; loop) · **Skipped** (only with the human's explicit confirmation that it isn't relevant). ### Re-Shaping — when what was agreed has to change Re-Shape when one of these happens, before the work that depends on it goes any further. A finding out of Verification or Validation reaches Re-Shaping at the milestone boundary; an assumption that breaks mid-Generation stops *that* work now rather than at the end of the milestone. What you may never do is note it and keep building: - a Hingepoint resolves differently from what the spec or plan assumed; - a review or validation finding shows the agreed approach is wrong; - an assumption you were building on turns out not to hold; - the Intent moved — the human edited it, or the ticket now says something the snapshot doesn't. Then, in this order: 1. Say what changed and why, and which artifacts it touches. 2. Update **every affected `spec*.md` and `plan.md` together.** A change in approach or in requirements belongs in the spec, not only in the plan. A plan-only edit leaves the specs describing a solution nobody is building any more, and what was learned is lost. 3. Show the human what changed and why **before** anything is confirmed — the files, the sections, the reasoning. Nothing changes silently. 4. On explicit confirmation, add a new entry to `## Revision & sign-off` naming the trigger, and renew the sign-off marks nested under it once granted at the new revision. The edit lapsed the previous entry's marks; that entry itself stays untouched. 5. Commit spec and plan together, then resume against the confirmed spec. While the marks are lapsed the derived state has fallen back to Shaping and the Delivery Cycle is not running. That is the point: it stops work from continuing against an agreement that no longer holds. ### 8 · Commit One commit per milestone, once its gates have passed. In-progress work stays in the working tree until the milestone settles — that's what makes the commit log a truthful record of milestone state. ### Completing a Work Package The last milestone's commit does not end the Work Package. Reach Acceptance: set that register row to `reached`, copy `assets/acceptance-brief-template.md` into the Work Package directory as `acceptance-brief.md`, and stop. If the named acceptor is already in the session, walk the same headings in conversation instead of writing the file. Do not treat the package as done. A Hingepoint resolved by workaround (a mock, a fixture, a test-data generator, a replacement interface — proposed, never built unapproved) did not satisfy its original condition. Write a register note at that moment, anchored to the Hingepoint's ID: original condition not met, what the workaround is. Acceptance cannot close while any such residue is undispositioned. Each must be **removed**, **made permanent deliberately**, or **accepted with a stated reason** — the acceptor's call, listed in the Brief. Do not mark Acceptance `resolved` until every item has one of those three. If this Work Package is Evolution, set each bundled Insight to `resolved ()` when Acceptance itself resolves, not at the last milestone commit. Then freeze those rows. Read `references/evolution.md`. --- ## Reference Formats, for looking up when you need one. When to stop, when to Re-Shape and what each phase requires are all above; nothing here is a rule you'd otherwise miss. ### Calling a Hingepoint ``` HINGEPOINT — Situation: Needs: Options: Recommendation: ``` Then stop until the human decides. Three things can resolve it: the decision, delivery or approval arrives; a workaround removes the dependency (a mock, a fixture, a test-data generator — you may propose one, you don't build it unapproved); or new information changes what was agreed, which is Re-Shaping. If deciding needs an artifact — a UI mock, a spike, a data sample — resolve the Hingepoint by *producing that artifact* for a real review: the human views the UI in a browser, shows it to stakeholders. A preference poll is input, not a sign-off. ### Hingepoint Register Create `hingepoint-register.md` from `assets/hingepoint-register-template.md` at Planning, once the plan's first Hingepoint exists to place in it. The template carries the required columns as actual table columns — condition, point in the plan, input needed from, status, and the four timestamps Flow Uptime (Chapter 11 of the Guide) depends on — so a required field can't be dropped by omission. A Hingepoint closes only when its stated condition is actually met — for a sign-off Hingepoint, when the human signed off on the real artifact, not when they indicated they probably would. This register is the basis for Flow Uptime, so record a Hingepoint when it becomes relevant rather than when it's convenient: a late entry inflates the measure and hides where the organisation is waiting. ### Insight Register Create `insight-register.md` from `assets/insight-register-template.md` on adoption, or when the first Insight is written if the file is missing. One per project or Rulebase. Ask where it should live; suggest `hingepoint/`. Do not restate its columns here. ### Acceptance Brief When Acceptance is reached, copy `assets/acceptance-brief-template.md`. The template's headings are the required contents. Write the file by default; conversation only if the named acceptor is already in the session. Do not restate the headings here.