informed-decision/docs/gate-house-decision-request-layer-placement.md

Decision request to gate-house — layer placement and approver-UI ownership

From: informed-decision Raised: 2026-09-09 Intake: INFD-IN-0001 Blocks: INFD-WP-0001-T02, and through it T05 and T07 Standard: net-kingdom/canon/standards/security-layer-model_v0.7.md, companion v0.2

---

1. The gap being closed

approval-engine names an approvals inbox under Non-Goals, deliberately and correctly — an engine that renders its own object is self-dealing, and the same reasoning kept the approval object out of access-engine.

The consequence is that the surface a human actually touches has no owner. This is no longer theoretical:

• approval-engine is a bearer-token resource server with no Ingress, no redirect endpoint and no browser client (deploy/approval-engine.yaml is Namespace + ClusterIP + StatefulSet).
• On 2026-09-08 key-cape (KEY-WP-0013-T02) asked approval-engine for the human approver client's client_id and full callback URI.
• approval-engine declined to invent them and recorded in docs/keycape-service-registrations.md: "The human approver flow therefore belongs to whichever browser-facing approver UI presents approval:approve tokens to this engine. That component is not in this repo and is not named in APPROVAL-WP-0002."
• APPROVAL-WP-0002-T01 remains progress in part because of it.

informed-decision exists to take this. We are not asking whether the work is ours to do. We are asking what layer the statute says we are, and asking it before we build, so the answer constrains the architecture rather than being retrofitted to it.

2. What is being asked

Three rulings, in dependency order. R3 is the one we least want to get wrong.

R1 — Layer and role

Proposal: informed-decision is PEP-shaped under statute §6.4 and owes companion §5.

Reasoning: it is browser-facing and it causes a protected side effect on the far side of a decision — it submits an approval entry to approval-engine carrying an authenticated human's identity. approval-engine's own INTENT anticipates exactly this class of caller: "Callers that do are PEP-shaped and owe companion §5 / statute §6.4."

We are not proposing an Engine row. We hold no state another layer reads at runtime to reach a verdict.

R2 — Does a presentation record make this a PIP as well?

informed-decision produces one fact other layers may want as a claim: what was presented, to whom, in what version — carried as view_hash. We do not evaluate that fact; we emit it.

Proposal: the presentation attestation is a PIP-like claim emitted by a PEP-shaped component, not a second catalog row. If the statute does not permit a component to be both, we ask which one governs and whether the presentation claim must instead be published as evidence to audit-core and read from there.

We flag §17: the shared request-claim schema has no assigned owner. Whatever shape we publish must yield to that schema when it exists rather than becoming a permanent local invention — the same position approval-engine took in APPROVAL-IN-0001.

R3 — view_hash versus the approval binding digest

This is the highest-risk item in the request and the reason it is filed before any code.

approval-engine's claim already carries "a digest over the same canonical binding the decision point already computes, so that approved and approved for this exact request are distinguishable at decision time."

informed-decision computes view_hash: a SHA-256 over a canonicalized binding document — the memo id and version, question, requested act, binding level, brief, locale, UI release, normalized packet and highlights, and the identity/scope being committed. Algorithm and vectors: history/20260909-initial-exploration/canonicalize.md.

These are not obviously the same hash, and they are not obviously different. Both claim to canonicalize "the binding". They differ in what they cover:

	approval-engine binding digest	informed-decision view_hash
Covers action, target, actor, principal, purpose	yes	yes, as binding
Covers the brief, packet and highlights shown to the human	no	yes
Covers locale and UI release	no	yes
Exists when no human is in the loop	yes	no
Purpose	replay protection at decision time	proof of what was presented

Three candidate rulings, with what each costs:

• (a) They are the same digest. Cleanest for the estate — one canonicalization, one authority. Cost: the approval binding digest would have to cover presentation material that does not exist for machine-to-machine approvals, or view_hash would have to drop the packet and highlights, which destroys the property this repository exists to provide.
• (b) view_hash is a distinct presentation attestation carried alongside the binding digest. Our proposal. Cost: two hashes over one act, requiring an explicit rule that the binding digest is authoritative for replay protection and view_hash is authoritative only for what was shown. Neither may be substituted for the other.
• (c) view_hash contains the binding digest as a field. Composition rather than duplication; view_hash becomes a superset commitment. Cost: ordering dependency — the approval must exist before a memo can be rendered.

We propose (b) and will implement whichever is ruled. What we ask gate-house to prevent is the outcome where both hashes ship without a stated relationship and the estate later discovers it has two canonicalizations of the same act with no rule for which one governs.

3. The self-dealing objection, stated against ourselves

A surface that renders both the question and the answer sits close to the objection that kept the approval object out of access-engine and the inbox out of approval-engine. We think it is not the same failure, and we would rather argue it here than be told later:

• access-engine could not own the approval object because an evaluator that owns what it evaluates can grade its own inputs.
• approval-engine could not own the inbox because an engine that renders its own object controls the presentation of the evidence it issues.
• informed-decision holds no state any layer reads as authority. It does not evaluate, does not issue the approval, and does not archive the trail. The presentation record is evidence about the act, produced by the party that performed the presentation — which is the only party that can produce it.

The residual we accept and do not paper over: a compromised surface can present X and attest Y. view_hash is computed by the same component that renders. This is structurally the same residual approval-engine names for adversarial omission at a compromised source, and we make the same claim it does — atomicity and attestation cover accident and later tampering, not a compromised source. We do not claim otherwise, and we ask that any ruling not credit us with closing it.

4. What we are not asking

• Not asking for approval doctrine. Which acts need approval, how many approvers, and which separations of duty apply stay gate-house's.
• Not asking to render decisions. No endpoint here answers "may this actor do X"; access-engine remains the only PDP.
• Not asking to hold approval state. approval-engine remains the sole mutator, and GH-DEC-2026-003 ordering is honoured unchanged.
• Not asking for a Railiance operational axis.

5. What we do on each answer

Ruling	Consequence
R1 confirms PEP-shaped	layer.yaml written as such; companion §5 declared shapes enumerated in T05
R1 places us elsewhere	INTENT.md, GOAL.md, SCOPE.md amended to match; the ruling wins
R2 permits a presentation claim	Published at our boundary, explicitly yielding to §17
R2 refuses it	Presentation evidence goes to audit-core only; no claim endpoint
R3 = (a)	One digest; view_hash is retired or redefined as its input
R3 = (b)	Both ship with a stated authority rule, recorded as a decision
R3 = (c)	Composition; memo rendering is ordered after approval issuance

Until R1 and R3 are answered, INFD-WP-0001-T05 (ArchitectureBlueprint) and T07 (the key-cape client registration) do not proceed. T03, T04 and T06 are independent of the ruling and continue.

6. Cost of delay

KEY-WP-0013-T02 is blocked today on two strings this repository now owns and cannot responsibly publish until it knows what it is. Registering a redirect URI for a component whose layer is unsettled is the drift statute §17 exists to prevent.