informed-decision/intakes/intakes.md
tegwick 5c33d17330 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
2026-09-10 07:57:57 +02:00

11 KiB

Intake records

INFD-IN-0001 — Layer placement and approver-UI ownership

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

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

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"