Apply GH-DEC-2026-013 and GH-DEC-2026-014; close INFD-IN-0002

Two rulings landed and both corrected something.

GH-DEC-2026-013 accepted our binding-versus-awareness argument, wrote it into
the record as its §6, and did not change the outcome — it sharpened the defect.
Two different facts share one field named tenant: the act-scope, a property of
the act that our binding slice commits, and the principal's membership, a
property of the person that approval-engine exact-matches. Gate House's
correction stands: a binding slice that must commit the scope being entered
should commit that scope, not borrow a membership claim to stand in for it. Our
schema already does — binding.target IS the act-scope and is inside view_hash —
so no field was added, only a statement (PR-08) and a provenance record (PR-09),
since key-cape emits tenant as a bare string.

key-cape had already implemented registration-bound tenancy on 2026-09-09,
correct under both candidate rulings, so the fail-closed-at-first-use risk that
made us withhold the client strings was already retired. IN-0002 closed. The one
remaining input to T07 is the deployed origin.

GH-DEC-2026-014 granted commitment-only evidence and bounded it. It satisfies
non-alteration and NOT reconstructability, and must not be described otherwise
anywhere. It also corrected our wording of the gap: we wrote that it leaves us
able to erase the content, which understates it. Commitment-only moves integrity
out of our control and leaves availability entirely inside it — the party that
can withhold the content is the party the evidence is about. Limit 3's condition
reduced, not removed.

The grant carries a condition we did not propose and would not have thought of:
the path must assert that committed content exists and where custody sits, so
non-production is a finding attributable to the custodian rather than an
unremarkable blank. A commitment with no assertion that something is being
committed to is indistinguishable from a commitment to nothing. Booked as PR-53,
and marked not-a-reversal-candidate.

Recorded the meta-rule Gate House named, now in its third setting here: unknown
versus absent in the stance map, directory-asserted versus registration-supplied
in the tenant claim, erased versus never held in the evidence path. Wherever a
system reaches one appearance by two routes, the record must say which route.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V3W1dQG7GFFM9d94jFx7iR

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
This commit is contained in:
tegwick 2026-09-10 07:57:57 +02:00
parent 8b8a5cd6ef
commit 5c33d17330
7 changed files with 320 additions and 29 deletions

View file

@ -236,6 +236,105 @@ by reading that field. Never infer it from the shape of `subject_id` — a namin
convention is not a verified claim. Entries written before v4 are `null` and
must not be read as `human`.
## 8c. Act-scope is not membership — `GH-DEC-2026-013` §5
Gate House made the sharpest observation anyone has made about this object
model, and it is worth carrying in full because it changes what we record even
though it changes no field.
Two different facts are being asked to travel in one claim named `tenant`:
| Fact | Property of | Who needs it |
| --- | --- | --- |
| Which scope is this act being entered into | the **act** | this repository's binding slice |
| Which tenant is this person a member of | the **principal** | `approval-engine`'s exact-match admission |
> *"A binding slice that must commit the scope being entered should commit THAT
> SCOPE, not borrow a membership claim to stand in for it."*
**Our schema already does the right thing.** `binding.target` is the act-scope:
the tenant, environment and system being entered, committed in the binding
document and therefore inside `view_hash`. It is not derived from, and must
never be replaced by, the token's `tenant` claim.
What was missing is not a field but a **statement and a record**:
- `binding.target` is the authoritative act-scope commitment. The `tenant` claim
is a membership fact about the principal and is **not** the act-scope.
- The two must never be collapsed. Where they agree, that agreement is itself a
fact worth recording; where they disagree, issuance is refused upstream
(`key-cape` `329e48f`) and this surface records the refusal rather than
choosing a winner.
- **The `tenant` claim's provenance is recorded.** `key-cape` emits `tenant` as
a bare string, so a consumer cannot tell a tenant the *directory asserted about
the person* from one a *registration supplied about the client they came
through*. `GH-DEC-2026-013` §5 requires the claim to carry its provenance;
until it does, this surface records which route the value arrived by rather
than storing an undifferentiated string.
This is the same rule as `unknown` versus `absent` in the stance map and
`erased` versus `never held` in §8d: **wherever a system reaches one appearance
by two routes, the record must say which route**, or the safer reading becomes
unavailable to everyone.
## 8d. What commitment-only does and does not establish — `GH-DEC-2026-014`
Commitment-only emission is **granted for Stage 1**. It is granted on the test
`GH-DEC-2026-013` set: its distinguishing case fails closed. A reviewer who
cannot obtain the content gets **no** reconstruction rather than a **wrong** one.
**It satisfies non-alteration. It does not satisfy reconstructability, and must
not be described as doing so** — not here, not in `audit-core`'s documents, and
not in any conformance claim.
A commitment-only record is weaker than an archive in a specific way. An archive
proves records were not altered or truncated after arrival, never that one was
never sent (§2, E-04). A commitment additionally **does not carry what it commits
to**. It establishes that the commitment was made when it says and has not
changed. About *what was committed to* it establishes nothing — except
conditionally: **if** a document is later produced, whether it is the one.
### The gap, in the right words
An earlier draft of ours said commitment-only "leaves us able to erase the
content". That understates where the problem sits, and Gate House corrected it:
> **Commitment-only moves *integrity* out of our control and leaves
> *availability* entirely inside it. The party that can withhold the content is
> the party the evidence is about.**
That is the condition limit 3 exists to prevent, **reduced and not removed**. The
reduction is real. It is not sufficient alone — which is why the grant carries
the condition below.
### The condition that makes the grant safe
**Non-production must be detectable as a finding, not present as an absence.**
If the independent path holds only a commitment, a reviewer who asks for content
and gets nothing cannot distinguish *erased*, *withheld*, *lost*, and *never
held*. The absence reads as an unremarkable blank.
So the evidence path must carry, alongside the commitment:
1. an assertion that committed content **exists**, and
2. **where custody sits**,
such that failure to produce at retrieval is a **conformance failure
attributable to the custodian**.
> *A commitment with no assertion that something is being committed to is
> indistinguishable from a commitment to nothing.*
This is **not a reversal candidate**. If it proves expensive, the answer is a
cheaper mechanism for the same property, never removal of the property.
### Residual, again
Not closed, not credited. The existence assertion narrows the erasure gap — a
detectable non-production tells a reviewer something is missing and who owed it.
It does not produce the missing thing.
## 9. Signed attributes (L4+, horizon)
When AES/QES arrives, the signed attributes carry `memo_id`, `memo_version`,