From 0a1d1d942acb14a2af43504cdd501acf118ec67b Mon Sep 17 00:00:00 2001 From: tegwick Date: Wed, 9 Sep 2026 22:10:45 +0200 Subject: [PATCH] Rule INFD-IN-0001: PEP-shaped, presentation claim permitted, view_hash distinct MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit informed-decision filed three rulings before writing any architecture, with candidate answers, their costs, the self-dealing objection argued against itself, and a list of what it was not asking for. That order is what section 17 exists to produce, and KEY-WP-0013-T02 is blocked today, so it is answered now rather than queued. R1 — PEP-shaped, confirmed as proposed, not an Engine. It holds no state another layer reads at runtime for a verdict, which is the test. Its layer stays its own to declare; this settles its shape, which is what was blocking. It should build to v0.8's obligation 3 rather than v0.7's and inherit GH-DEC-2026-010's attribution gap knowingly rather than describe its validation as complete. R2 — yes, and no second catalog row. PEP and PIP are shapes a repository has; the catalog records layers it occupies. Obligation 5 forbids a PIP republishing the PDP's decision, which is a prohibition on republishing a decision, not on holding two shapes. Three limits carry the permission: the claim carries presentation and nothing else, it must never be an input to the decision it presents for, and its evidence copy reaches audit-core independently of the emitter. The last is the one that matters here, because the actor and the source are the same component. R3 — candidate (b). The binding digest is authoritative for what the request is; view_hash only for what was shown; a disagreement between them is a finding against the presenting surface, never a fact about the request. (a) is refused doctrinally rather than on the cost given: merging the two makes one repository the authority on what another layer computes over a request, which is GH-DEC-2026-008's objection to translation. (c) is refused because nesting the binding digest inside view_hash reproduces the hash cycle that made GH-DEC-2026-008 unimplementable — we paid for that lesson once this quarter. The two link by co-reference instead: the presentation record names the binding identifier and never recomputes the other layer's digest. The residual is not closed and the ruling says so, as they asked. A compromised surface can present X and attest Y. Attestation covers accident and later tampering, never a compromised source — the same disposition approval-engine's equivalent takes. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_012viPor8WJNCbV64ipwewrm Assistant: claude-code Assistant-Model: opus Assistant-Process: 1754332@bnt-lap001 Assistant-Session: 9c8ac536-ff5e-46a3-8ab1-a548bde25fc0 --- WORK-RECORDS.md | 25 ++++- decisions/decisions.md | 207 +++++++++++++++++++++++++++++++++++++++++ intakes/intakes.md | 1 + 3 files changed, 230 insertions(+), 3 deletions(-) diff --git a/WORK-RECORDS.md b/WORK-RECORDS.md index 1a605cc..a27f197 100644 --- a/WORK-RECORDS.md +++ b/WORK-RECORDS.md @@ -8,21 +8,40 @@ | Kind | ID | Status | Lane | Source | | --- | --- | --- | --- | --- | -| workplan | GH-WP-0001 | active | — | workplans/GH-WP-0001-foundation.md | +| workplan | GH-WP-0001 | finished | — | workplans/GH-WP-0001-foundation.md | | workplan | GH-WP-0002 | finished | — | workplans/GH-WP-0002-approval-evidence-integrity.md | +| workplan | GH-WP-0003 | finished | — | workplans/GH-WP-0003-statute-v08-amendment-set.md | | task | GH-WP-0001-T01 | done | — | workplans/GH-WP-0001-foundation.md | | task | GH-WP-0001-T02 | done | — | workplans/GH-WP-0001-foundation.md | | task | GH-WP-0001-T03 | done | — | workplans/GH-WP-0001-foundation.md | | task | GH-WP-0001-T04 | done | — | workplans/GH-WP-0001-foundation.md | -| task | GH-WP-0001-T05 | todo | — | workplans/GH-WP-0001-foundation.md | -| task | GH-WP-0001-T06 | todo | — | workplans/GH-WP-0001-foundation.md | +| task | GH-WP-0001-T05 | done | — | workplans/GH-WP-0001-foundation.md | +| task | GH-WP-0001-T06 | done | — | workplans/GH-WP-0001-foundation.md | | task | GH-WP-0002-T01 | done | — | workplans/GH-WP-0002-approval-evidence-integrity.md | | task | GH-WP-0002-T02 | done | — | workplans/GH-WP-0002-approval-evidence-integrity.md | | task | GH-WP-0002-T03 | done | — | workplans/GH-WP-0002-approval-evidence-integrity.md | | task | GH-WP-0002-T04 | done | — | workplans/GH-WP-0002-approval-evidence-integrity.md | | task | GH-WP-0002-T05 | done | — | workplans/GH-WP-0002-approval-evidence-integrity.md | | task | GH-WP-0002-T06 | done | — | workplans/GH-WP-0002-approval-evidence-integrity.md | +| task | GH-WP-0003-T01 | done | — | workplans/GH-WP-0003-statute-v08-amendment-set.md | +| task | GH-WP-0003-T02 | done | — | workplans/GH-WP-0003-statute-v08-amendment-set.md | +| task | GH-WP-0003-T03 | done | — | workplans/GH-WP-0003-statute-v08-amendment-set.md | +| task | GH-WP-0003-T04 | done | — | workplans/GH-WP-0003-statute-v08-amendment-set.md | +| task | GH-WP-0003-T05 | done | — | workplans/GH-WP-0003-statute-v08-amendment-set.md | +| task | GH-WP-0003-T06 | done | — | workplans/GH-WP-0003-statute-v08-amendment-set.md | +| task | GH-WP-0003-T07 | done | — | workplans/GH-WP-0003-statute-v08-amendment-set.md | +| task | GH-WP-0003-T08 | done | — | workplans/GH-WP-0003-statute-v08-amendment-set.md | +| task | GH-WP-0003-T09 | done | — | workplans/GH-WP-0003-statute-v08-amendment-set.md | | intake | GH-IN-0001 | closed | red | intakes/intakes.md | +| intake | GH-IN-0002 | closed | red | intakes/intakes.md | | decision | GH-DEC-2026-001 | resolved | — | decisions/decisions.md | | decision | GH-DEC-2026-002 | resolved | — | decisions/decisions.md | | decision | GH-DEC-2026-003 | resolved | — | decisions/decisions.md | +| decision | GH-DEC-2026-004 | resolved | — | decisions/decisions.md | +| decision | GH-DEC-2026-005 | resolved | — | decisions/decisions.md | +| decision | GH-DEC-2026-006 | resolved | — | decisions/decisions.md | +| decision | GH-DEC-2026-007 | resolved | — | decisions/decisions.md | +| decision | GH-DEC-2026-008 | resolved | — | decisions/decisions.md | +| decision | GH-DEC-2026-009 | resolved | — | decisions/decisions.md | +| decision | GH-DEC-2026-010 | resolved | — | decisions/decisions.md | +| decision | GH-DEC-2026-011 | resolved | — | decisions/decisions.md | diff --git a/decisions/decisions.md b/decisions/decisions.md index 161b412..2d03e38 100644 --- a/decisions/decisions.md +++ b/decisions/decisions.md @@ -190,6 +190,7 @@ rationale: 'Approved as GH-WP-0002-T03. Local-outbox fail-closed is the only rem for load-bearing approval evidence.' decided_by: Bernd Worsch decided_at: '2026-08-29T12:50:58.873684Z' +state_hub_decision_id: "3b7c8336-ed0b-48ed-84e4-dee8cfdb50ae" ``` ## Context @@ -280,6 +281,7 @@ rationale: Approved as GH-WP-0002-T06. The PEP consumes by compare-and-swap befo This closes the three named races and unblocks APPROVAL-WP-0001-T05 and FLEX-WP-0017-T05. decided_by: Bernd Worsch decided_at: '2026-08-29T12:51:01.355583Z' +state_hub_decision_id: "f768c894-7e68-4e23-93b5-f475f4b072e5" ``` ## Context @@ -700,6 +702,7 @@ rationale: 'A statute of record should not carry state, and §13 and §13.1 are decided_by: Bernd Worsch created: '2026-09-05T23:38:49.777532Z' updated: '2026-09-05T23:38:49.777532Z' +state_hub_decision_id: "780e1117-57aa-49c7-bf59-f69df2a67a4e" ``` ## Context @@ -816,6 +819,7 @@ rationale: 'Adopted with one addition. kings-guard is right that volatility desc decided_by: Bernd Worsch created: '2026-09-06T06:07:34.017316Z' updated: '2026-09-06T06:07:34.017316Z' +state_hub_decision_id: "9ece3338-0fc7-4741-bdfc-7fdea170dc0b" ``` ## Context @@ -977,6 +981,7 @@ rationale: 'Raised by access-engine. approval-claim verification item 4 is a dis decided_by: Bernd Worsch created: '2026-09-06T07:30:42.213794Z' updated: '2026-09-06T07:30:42.213794Z' +state_hub_decision_id: "a36b3f02-fb08-47b5-9de3-c2d9e37678a4" ``` ## Context @@ -1111,6 +1116,7 @@ rationale: 'Raised by access-engine on the first occasion the §13.1 register he decided_by: Bernd Worsch created: '2026-09-06T12:17:19.104531Z' updated: '2026-09-06T12:17:19.104531Z' +state_hub_decision_id: "009bc960-9029-4052-aaba-4c5e27a328dc" ``` ## Context @@ -1341,6 +1347,7 @@ rationale: 'Raised by access-engine against its own artifact during the v0.8 ass 13 rather than papered by a rule the standard does not get to choose.' created: '2026-09-09T18:11:20.071372Z' updated: '2026-09-09T18:11:20.071372Z' +state_hub_decision_id: "046aa117-5b33-4fc2-b88c-313ad40f8e45" ``` ## Context @@ -1490,6 +1497,7 @@ rationale: 'ops-warden assented to GH-DEC-2026-009 on its own terms and then rep from an unknown one and surface as a conformance failure.' created: '2026-09-09T18:12:02.553370Z' updated: '2026-09-09T18:12:02.553370Z' +state_hub_decision_id: "6777f9d1-566d-4bc7-815e-e08582b8719a" ``` ## Context @@ -1625,3 +1633,202 @@ nothing — it is not PEP-shaped and publishes no stance map — and that a PDP' a ruling falling entirely on other repositories is weak evidence for it. That is recorded because it is right: the strength here is the asymmetry argument and `ops-warden`'s assent against its own interest, not the count of repositories agreeing. + +## GH-DEC-2026-012 — informed-decision is PEP-shaped and may emit a presentation claim; view_hash and the binding digest are distinct and non-substitutable + +```yaml +id: GH-DEC-2026-012 +kind: decision +title: informed-decision is PEP-shaped and may emit a presentation claim; view_hash + and the binding digest are distinct and non-substitutable +status: resolved +owner: Bernd Worsch +repo: gate-house +standard: net-kingdom/canon/standards/security-layer-model_v0.8.md +source_note: informed-decision/docs/gate-house-decision-request-layer-placement.md + (INFD-IN-0001; hub intake 01a08610) +requested_dispositions: +- approved +- revised +- rejected +affects: +- gate-house +- informed-decision +- approval-engine +- access-engine +- audit-core +- key-cape +- net-kingdom +decided_by: Bernd Worsch +rationale: 'Three rulings requested before any architecture was written. R1: informed-decision + is PEP-shaped under section 6.4 and owes companion section 5, because it causes + a protected side effect on the far side of a decision. It is not an Engine and holds + no state another layer reads at runtime for a verdict. R2: a component may be PEP-shaped + and also emit a claim; PEP and PIP are shapes a repository has, not layers it occupies, + and the catalog rows are layers. The presentation claim is permitted as a claim + about presentation only, subject to three limits: it must not carry, restate or + imply the decision or the approval verdict, it must not be an input to the decision + it presents for, and its evidence copy reaches audit-core independently of the emitter. + R3: candidate (b). view_hash and the approval binding digest are distinct attestations + with an explicit authority rule. (a) is refused because merging them would make + one repository the authority on what another layer computes over a request, which + is the objection GH-DEC-2026-008 made to translation. (c) is refused because nesting + the binding digest inside view_hash creates an ordering dependency and reproduces + the hash-cycle shape that made GH-DEC-2026-008 unimplementable. The binding digest + is authoritative for what the request is; view_hash is authoritative only for what + was shown; neither may be substituted for the other, and a disagreement between + them is a finding against the presenting surface rather than a fact about the request.' +created: '2026-09-09T20:09:49.402289Z' +updated: '2026-09-09T20:09:49.402289Z' +``` + +## Context + +`informed-decision` is a new repository claiming the browser-facing approver UI that +`approval-engine` names under its own Non-Goals. It filed `INFD-IN-0001` **before +writing any architecture**, asking for three rulings and stating what it would do on +each possible answer, including the answers it did not want. That order — ruling first, +architecture second — is what §17 exists to produce and it is worth recording as the +reason this was answered inside a day. + +It also argued the self-dealing objection against itself in §3 of its request, and asked +that no ruling credit it with closing the residual it named. That request is honoured +below. + +## Decision + +### R1 — `informed-decision` is PEP-shaped, and is not an Engine + +**Confirmed as proposed.** It causes a protected side effect on the far side of a +decision: it submits an approval entry carrying an authenticated human's identity. §6.4 +applies in full, and companion §5 is owed. + +It is **not** an Engine and takes no catalog row as one. It holds no state another layer +reads at runtime to reach a verdict, which is the test, and it renders no decision. + +Being PEP-shaped does not move a repository out of its layer (§6.4). Its layer is its +own to declare in its own voice; this ruling settles its *shape*, which is what was +asked and what was blocking. + +Consequences it should expect, stated so they are not discovered later: + +- A published unreachable-engine stance map at a path named in its layer declaration, + and a row in statute §13.1. Build to **v0.8's** obligation 3 rather than v0.7's: + `unknown` MUST resolve to `fail_closed`, the map MUST enumerate its axis rather than + lean on a catch-all, an `absent` scope MUST be distinguishable in the record from an + `unknown` one, and the test asserting published-equals-shipped is a `MUST`. Publish a + classification-coverage figure beside the stance (`GH-DEC-2026-011`). +- §6.4 obligation 1 in its v0.8 form, including the attribution property it cannot + satisfy today (`GH-DEC-2026-010`). It inherits a declared gap, not a clean path, and + its own documents must say so rather than describing validation as complete. + +### R2 — Yes, and it is not a second catalog row + +**A component may be PEP-shaped and also emit a claim.** PEP and PIP are *shapes* a +repository has; the §4 catalog records *layers* a repository occupies. Nothing in the +statute forbids one component having two shapes, and the rule that looks like it does — +§6.4 obligation 5's *"a PIP MUST NOT republish the PDP's decision"* — is a prohibition on +**republishing a decision**, not on holding two shapes. `informed-decision` proposed +exactly this reading and it is right. + +Three limits, and they are the substance of the permission: + +1. **The presentation claim carries presentation and nothing else.** It MUST NOT carry, + restate, summarise, or imply the decision, the approval verdict, or whether the act + was permitted. A consumer must not be able to learn from this claim anything about + what was *decided* — only about what was *shown*. This is obligation 5 applied at + issue rather than at consumption. +2. **It MUST NOT be an input to the decision it presents for.** Presentation is evidence + about conduct, never a source of authority. A policy that reads `view_hash` to decide + whether an act is permitted would let the presenting surface contribute to its own + authorization, which is the estate's oldest rule in a new place: cognition proposes, + authority disposes. +3. **The evidence copy reaches `audit-core` independently of the emitter.** The claim + endpoint and the evidence path are different things and one does not substitute for + the other. Audit evidence is protected from the actor being audited, and here the + actor and the source are the same component — so the copy that is evidence must not + be reachable only through the party it is evidence about. + +**The §17 yield is accepted as offered.** Whatever shape `informed-decision` publishes +yields to the shared request-claim schema when that schema has an owner, which it does +not yet (§17 records request-claim and gap-record as the two unsettled artifacts). The +position matches `approval-engine`'s in `APPROVAL-IN-0001` and is the right one: a local +invention declared temporary is tolerable, a local invention declared permanent is the +drift §17 exists to prevent. + +### R3 — Candidate (b): distinct attestations, with the authority rule stated + +**`view_hash` and `approval-engine`'s binding digest are two attestations over one act, +and neither may be substituted for the other.** + +- **The binding digest is authoritative for what the request *is*.** Replay identity, + correspondence with the decision, and everything §6.4 obligation 5 governs. +- **`view_hash` is authoritative only for what was *shown*.** It attests presentation: + brief, packet, highlights, locale, UI release, and the binding material as rendered. +- **A disagreement between them is a finding against the presenting surface, never a + fact about the request.** This is the rule that keeps the two from becoming rival + answers to one question, and it is the thing `informed-decision` asked us to prevent. + +**(a) is refused, and for a doctrinal reason rather than the cost given.** One digest +means one canonicalization authoritative for both, and the material is owned by +different layers: what a request *is* is computed by the decision path, what was *shown* +is known only to the presenting surface. Merging them makes one repository the authority +on what another layer computes over a request — a third authority on what a request is, +which is precisely the objection `GH-DEC-2026-008` made to cross-engine translation. The +cost `informed-decision` names is real and secondary: the binding digest must exist where +no human is in the loop, and `view_hash` cannot exist there at all. + +**(c) is refused for two reasons, the second the stronger.** First, the ordering +dependency it admits: an approval would have to exist before a memo could be rendered, +which inverts the flow this repository exists to serve. Second, and this is why we will +not take it even if the ordering were acceptable — nesting one hash inside the other +reproduces the shape that made `GH-DEC-2026-008` unimplementable. That ruling required a +claim to name the digest of a request that would come to contain the claim: a hash cycle, +found by `secrets-engine` and reported independently by two engines within hours. If +`view_hash` ever travels inside hashed request material while containing the binding +digest, the same cycle reappears with the same fail-closed consequence. We have paid for +that lesson once this quarter and are not buying it a second time. + +**How the two are linked, since they are no longer linked by nesting.** By +**co-reference, not by translation**: the presentation record carries the approval or +binding identifier explicitly, and both attestations are read against that one reference. +`informed-decision` MUST NOT recompute or restate `approval-engine`'s binding digest from +its own vocabulary — it references the digest the other layer computed and recorded. That +is `GH-DEC-2026-008`'s identity-not-translation rule applied here, and it is why the two +canonicalizations covering overlapping material is not a defect: they answer different +questions and are compared to nothing. + +## The residual, not closed and not credited + +`informed-decision` stated it against itself and asked not to be credited with closing +it. **It is not closed, and this ruling does not close it.** A compromised surface can +present X and attest Y, because `view_hash` is computed by the component that renders. + +That is structurally the same residual `approval-engine` names for adversarial omission +at a compromised source, and it takes the same disposition: attestation and atomicity +cover accident and later tampering, never a compromised source. It belongs in the same +register as §6.4 obligation 5's summary-predicate residual and §9.6's — detection, not +prevention. + +The §3 argument that this is *not* the failure that kept the approval object out of +`access-engine` is accepted. An evaluator owning what it evaluates can grade its own +inputs; a renderer attesting its own rendering is the only party able to produce the +record at all. The distinction holds — but limit 2 above is what keeps it holding, and +without it the two collapse. + +## Reversal condition + +R2's permission reverses if a presentation claim is ever found carrying decision +content, or if a policy is found reading `view_hash` as an authorization input. Either +would mean the shape cannot be held safely by one component and the claim moves to +`audit-core` as the request's own R2-refused branch describes. + +R3 §(b) reverses if the shared request-claim schema (§17) arrives with a presentation +attestation already in it, in which case the local shape yields as offered. + +## Provenance + +Requested by `informed-decision` (`INFD-IN-0001`, hub intake `01a08610`) before writing +its architecture, with three candidate rulings, their costs, the self-dealing objection +argued against itself, and an explicit list of what it was *not* asking for. Unblocks +`INFD-WP-0001` T05 and T07, and `KEY-WP-0013-T02`. diff --git a/intakes/intakes.md b/intakes/intakes.md index 971fd14..5fecdd9 100644 --- a/intakes/intakes.md +++ b/intakes/intakes.md @@ -161,4 +161,5 @@ description: 'approval-engine asks gate-house to confirm which artifact satisfie Requested disposition is a confirmation, not a redesign. Resolved as GH-DEC-2026-005.' created: '2026-09-05T23:28:11.977565Z' updated: '2026-09-05T23:28:11.977565Z' +state_hub_intake_id: "01a08762-ab47-7163-8eeb-92c3cb909db3" ```