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
204 lines
11 KiB
Markdown
204 lines
11 KiB
Markdown
# Intake records
|
|
|
|
## INFD-IN-0001 — Layer placement and approver-UI ownership
|
|
|
|
```yaml
|
|
id: INFD-IN-0001
|
|
kind: intake
|
|
title: Layer placement and approver-UI ownership
|
|
status: closed
|
|
origin: coordination
|
|
origin_ref: INFD-WP-0001-T02
|
|
priority: high
|
|
owner: gate-house
|
|
repo: informed-decision
|
|
lane: blue
|
|
tags:
|
|
- decision-request
|
|
- cross-repo
|
|
created: '2026-09-09'
|
|
updated: '2026-09-09'
|
|
resolution: >-
|
|
Resolved 2026-09-09 as GH-DEC-2026-012 (gate-house@0a1d1d9), within a day of
|
|
filing. All three ruled. R1: PEP-shaped, confirmed as proposed; the ruling
|
|
settles the shape, the layer stays this repository's to declare, so layer.yaml
|
|
is written in its own voice. R2: yes to a presentation claim and no second
|
|
catalog row — PEP and PIP are shapes a repository has — under three limits now
|
|
declared and tested in layer.yaml; limit 2 (never an input to the decision it
|
|
presents for) is load-bearing, since the self-dealing argument was accepted
|
|
because it holds. R3: option (b) as proposed, with the authority rule written
|
|
down — the binding digest is authoritative for what the request is, view_hash
|
|
only for what was shown, neither substitutable, and a disagreement between
|
|
them is a finding against the presenting surface rather than a fact about the
|
|
request. Linkage is co-reference; (c) was refused because nesting reproduces
|
|
the GH-DEC-2026-008 hash cycle. Also directed: build the stance map to v0.8
|
|
obligation 3 rather than migrate later, and inherit GH-DEC-2026-010 as a
|
|
declared open gap. Delivered in layer.yaml, pep-stance.yaml,
|
|
informed_decision/stance.py and tests/test_layer_conformance.py.
|
|
description: >-
|
|
approval-engine names an approvals inbox under Non-Goals, leaving the
|
|
browser-facing approver UI unowned; key-cape KEY-WP-0013-T02 is blocked on a
|
|
client_id and callback URI no component has claimed, and approval-engine
|
|
recorded in docs/keycape-service-registrations.md that they must come from
|
|
that component's owner. informed-decision claims the surface and asks
|
|
gate-house to rule on three things before any code is written: (R1) layer and
|
|
role, proposed PEP-shaped under statute §6.4 and companion §5; (R2) whether a
|
|
presentation attestation makes this a PIP as well, or whether presentation
|
|
evidence must reach consumers only via audit-core, noting §17 has no assigned
|
|
request-claim schema owner; (R3) the relationship between informed-decision's
|
|
view_hash and approval-engine's binding digest, which both claim to
|
|
canonicalize "the binding" but cover different material. R3 is the highest
|
|
risk: shipping both without a stated authority rule leaves the estate with two
|
|
canonicalizations of one act. Proposal is (b) — distinct attestations with the
|
|
binding digest authoritative for replay and view_hash authoritative only for
|
|
what was shown. Full request: docs/gate-house-decision-request-layer-placement.md.
|
|
Blocks INFD-WP-0001 T05 and T07; T03, T04 and T06 proceed regardless.
|
|
state_hub_intake_id: "01a08610-f458-7fd5-b284-26a65d1d73c2"
|
|
```
|
|
|
|
## INFD-IN-0002 — Human access tokens cannot carry `tenant:platform`
|
|
|
|
```yaml
|
|
id: INFD-IN-0002
|
|
kind: intake
|
|
title: Human access tokens cannot carry tenant:platform
|
|
status: closed
|
|
origin: coordination
|
|
origin_ref: INFD-WP-0001-T07
|
|
priority: high
|
|
owner: key-cape
|
|
repo: informed-decision
|
|
lane: blue
|
|
tags:
|
|
- decision-request
|
|
- cross-repo
|
|
- blocker
|
|
created: '2026-09-09'
|
|
updated: '2026-09-10'
|
|
resolution: >-
|
|
Resolved 2026-09-10. key-cape had already implemented registration-bound
|
|
tenancy on 2026-09-09 (329e48f), deliberately correct under both candidate
|
|
rulings: a declared zone applies where the directory places the user nowhere,
|
|
agreement passes, and a declared zone conflicting with a directory assignment
|
|
refuses issuance with 403 tenant_binding rather than relabelling. So the risk
|
|
that a client registered now fails closed at first use was already retired.
|
|
GH-DEC-2026-013 then ruled directory-sourced the terminal state and granted
|
|
the registration-bound shape as a declared bounded gap — admissible precisely
|
|
because its distinguishing case fails closed. This repository's
|
|
binding-versus-awareness argument was accepted and written into the ruling as
|
|
its §6; it did not change the outcome but sharpened the defect, which is that
|
|
two different facts share one field named tenant: the act-scope (a property of
|
|
the act, which our binding slice commits) and the principal's membership (a
|
|
property of the person, which approval-engine exact-matches). Gate House's
|
|
correction of our position is adopted: a binding slice that must commit the
|
|
scope being entered should commit that scope, not borrow a membership claim to
|
|
stand in for it — and binding.target already does, so no field was added, only
|
|
a statement and a provenance record. The condition we asked for is in
|
|
key-cape's docs/tenant-claim-contract.md, strengthened from "must be revisited"
|
|
to void if the dynamic-registration exclusion is lifted, and enforced by a test
|
|
asserting the capability and the exclusion together. Two obligations land here
|
|
and are booked as PR-08 and PR-09: do not use the tenant claim as the
|
|
act-scope, and record the claim's provenance since key-cape emits it as a bare
|
|
string. T07 unblocked.
|
|
description: >-
|
|
Raised by key-cape (KEY-WP-0013-T05) while reviewing the approver client
|
|
shape, and it blocks INFD-WP-0001-T07. The tenant claim on a human token
|
|
resolves from the directory user record via effectiveTenant(user); no adapter
|
|
populates domain.User.Tenant, so every human token falls back to the platform
|
|
default tenant:coulomb. The per-client tenant field, which is how the two
|
|
approval service clients carry tenant:platform, is read only on the
|
|
client_credentials path. approval-engine compares tenant by exact string
|
|
equality and pins near-miss spellings as refused, so an approver token issued
|
|
today would be rejected and the failure would surface as a rejected approval
|
|
rather than as a registration defect. Two resolutions: directory-sourced
|
|
(tenant becomes a property of the person and changes everywhere, needs a
|
|
directory attribute and an owner for who is a platform-zone human), or
|
|
registration-bound and fail-closed (symmetric with the service registrations
|
|
and with decision 5ed3fb35, but writes a cross-tenant capability into the
|
|
issuer). informed-decision prefers registration-bound: under it the tenant is
|
|
a property of the surface and its registration, which is exactly what the
|
|
pre-sign binding slice commits, whereas directory-sourced makes tenant
|
|
describe the person, which is closer to awareness than to binding. key-cape
|
|
leans the same way but will not implement either unilaterally. Not this
|
|
repository's to decide alone; routed to key-cape, approval-engine and
|
|
gate-house. If registration-bound is chosen, the condition that it holds only
|
|
because registrations are static and deployment-owned should be written into
|
|
the contract rather than left as reasoning in a message. Blocks T07; the
|
|
client_id and callback URI will not be published until it is resolved, since
|
|
registering a client that fails closed at first use is the failure key-cape
|
|
flagged.
|
|
state_hub_intake_id: "01a0880b-36f8-7d89-ab67-2c91ee16f300"
|
|
```
|
|
|
|
## INFD-IN-0003 — The independent evidence path: what travels to audit-core
|
|
|
|
```yaml
|
|
id: INFD-IN-0003
|
|
kind: intake
|
|
title: The independent evidence path — what travels to audit-core
|
|
status: open
|
|
origin: residual
|
|
origin_ref: INFD-WP-0001-T05
|
|
priority: high
|
|
owner: audit-core
|
|
repo: informed-decision
|
|
lane: blue
|
|
tags:
|
|
- decision-request
|
|
- cross-repo
|
|
created: '2026-09-09'
|
|
updated: '2026-09-10'
|
|
resolution_partial: >-
|
|
Doctrine half ruled 2026-09-10 as GH-DEC-2026-014; the payload remains
|
|
audit-core's custody question and the intake stays open for it. Commitment-only
|
|
is GRANTED for Stage 1, on the GH-DEC-2026-013 test that its distinguishing
|
|
case fails closed — a reviewer who cannot obtain the content gets no
|
|
reconstruction rather than a wrong one — and the data-protection reason was
|
|
accepted as a reason of the right kind, since doctrine forcing L4 contract text
|
|
into an audit fabric trades one control for a breach of another. Two limits:
|
|
it satisfies non-alteration and NOT reconstructability, and must not be
|
|
described otherwise in any document or conformance claim on either side; and
|
|
our wording of the gap was corrected — commitment-only moves integrity out of
|
|
our control and leaves availability entirely inside it, so the party that can
|
|
withhold the content is the party the evidence is about, which is limit 3's
|
|
condition reduced rather than removed. The grant carries a condition we did not
|
|
propose (§4): the path must carry an assertion that committed content exists
|
|
and where custody sits, so that 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. Not a reversal candidate. Our refusal of a separate evidence store was
|
|
endorsed, with the addition that an evidence store owned by the party whose
|
|
conduct it evidences is not an evidence store whatever its integrity
|
|
properties, the ownership objection being prior to the custody one. Booked as
|
|
PR-53 and PR-54 and EvidenceModel §8d. Still open for audit-core: sender
|
|
registration, and whether reconciliation plus heartbeat suits a mixed-volume
|
|
source.
|
|
description: >-
|
|
GH-DEC-2026-012 limit L3 requires the evidence copy to reach audit-core
|
|
independently of informed-decision, because here the actor being audited and
|
|
the evidence source are the same component. Read independence and a local
|
|
transactional outbox are settled and not in question. The open question is
|
|
what travels, and it is sharper here than for approval-engine because a
|
|
presentation record contains the brief and packet material actually shown to a
|
|
human, which is frequently commercially or personally sensitive. Three
|
|
candidates with costs are in docs/evidence-path-design.md: (a) commitment only
|
|
— hashes, principal, timestamps, acks, co-referenced approval id — which
|
|
discharges limit 3 and removes our ability to alter the record but not to
|
|
erase the content; (b) the full binding document, which survives our
|
|
compromise but puts commercial and personal material into the audit fabric
|
|
under retention and export entitlements designed for audit events, a
|
|
meaningful change in what audit-core holds and its owner's to accept or
|
|
refuse; (c) a split with a separate evidence store, refused here because that
|
|
store has no owner and inventing one routes around the §16 decision against
|
|
stronger archival custody. informed-decision proposes (a) for Stage 1 with the
|
|
erasure residual declared alongside the existing compromised-surface residual,
|
|
and asks whether the content question is audit-core's as custodian or
|
|
gate-house's as doctrine. Also requests a sender registration and asks whether
|
|
reconciliation plus a heartbeat for low-volume classes is the right cadence
|
|
form for a mixed-volume source — presentations are high-volume, dispositions
|
|
and stance applications are low-volume and are the security-relevant ones.
|
|
Cadence depends on AUDIT-WP-0009 T04/T06 and is declared, not claimed
|
|
operating. The registration tenant is coupled to INFD-IN-0002. Blocks
|
|
INFD-WP-0001-T08.
|
|
state_hub_intake_id: "01a0880b-4421-747b-9e7f-6e9bff9d2ea3"
|
|
```
|