Record and ratify intent
Capture the human decision behind observed architecture, with evidence, an accountable owner, and explicit approval.
Context is the situation your sources describe. Intent is the decision someone made in response, together with the reasons and conditions that support it. Hyperoru can observe context; a person must supply and ratify intent.
Start from observed context
Open Intent → Record intent and choose an evidence baseline. The form needs a complete architecture snapshot with supporting observations. A reviewed source archive can provide that baseline; a repository provider is not required to record a decision.
The signed-in person owns the proposal. Select the observations that establish the context rather than using a generated explanation as a substitute for evidence.
Write a decision someone else can evaluate
| Field | What to record | Gateway example |
|---|---|---|
| Context | The facts and constraints that led to a decision. | The API has no authentication middleware; the gateway authenticates requests. |
| Decision | The choice being proposed. | Keep authentication at the gateway. |
| Rationale | Why that choice fits these circumstances. | Avoid duplicate processing on latency-sensitive requests. |
| Accepted trade-off | The cost or dependence you are accepting. | The API relies on the gateway boundary. |
| Alternative | A credible option you considered. | Authenticate requests again inside the API. |
| Guardrail | What must remain true for the decision to hold. | Every external request must pass through the gateway. |
| Supporting evidence | Observations establishing the situation. | Gateway route configuration, API code, and observed ingress configuration. |
Keep facts and choices separate. “There is no authentication middleware” does not mean “the team intentionally removed authentication.”
Save a proposal, then obtain approval
Saving the form creates a proposed decision. It does not ratify the choice. An authorized reviewer must explicitly select an option, enter an approval rationale, and approve it. The record keeps the approver's identity and approval time alongside the owner and revision.
If you cannot approve, ask an authorized workspace member to review the proposal. The workspace access guide explains role boundaries.
Decide how the guardrail can be checked
Supported structured checks can evaluate an entity, a relationship, or minimum source coverage against later evidence. Choose one only when it actually represents the condition you care about.
A prose guardrail such as “every request must authenticate” may require a person to inspect behavior and source coverage. Free text stays inconclusive during automatic verification; a written sentence is not an executable proof.
Revisit the decision when the evidence changes
The current design may still match its original rationale, or a changed path may undermine the guardrail. Read architecture drift to compare the observations before deciding whether to keep, revise, or replace a decision.
The public example demonstrates a fictional owner and ratification. Its local edits never create approvals in your workspace.