coulomb/gate-house
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Rule INFD-IN-0001: PEP-shaped, presentation claim permitted, view_hash distinct

Browse source 
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 <noreply@anthropic.com>
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
This commit is contained in:
tegwick 2026-09-09 22:10:45 +02:00
parent bed8832e10
commit 0a1d1d942a
3 changed files with 230 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

25
WORK-RECORDS.md
View file

@ -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 |

207
decisions/decisions.md
View file

@ -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`.

1
intakes/intakes.md
View file

@ -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"
```