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

## INFD-IN-0004 — approval-engine's R3 answer conflicts with GH-DEC-2026-012 R3

```yaml
id: INFD-IN-0004
kind: intake
title: approval-engine R3 answer conflicts with GH-DEC-2026-012 R3
status: open
origin: coordination
origin_ref: INFD-WP-0001-T02
priority: high
owner: gate-house
repo: informed-decision
lane: blue
tags:
- decision-request
- cross-repo
- finding
created: '2026-09-10'
updated: '2026-09-10'
description: >-
  GH-DEC-2026-012 R3 refused option (c) — view_hash containing approval-engine's
  binding digest as a field — and required linkage by co-reference, forbidding
  this repository from recomputing or restating that digest from its own
  vocabulary. approval-engine (docs/approval-claim.md, 62233c7) has since
  answered the same question and recommends exactly option (c): that our binding
  document carry their binding.digest as a field rather than re-canonicalize
  action/actor/principal/purpose/target ourselves, so there is one
  canonicalization of the act computed by the layer that owns it. We cannot
  comply with both. This is not a wording difference: our binding slice
  canonicalizes principal and target, two of the five fields in their digest, so
  co-reference by identifier alone leaves two independent canonicalizations of
  one act linked by a shared id — which GH-DEC-2026-012 manages with an
  authority rule rather than removes. New information the refusal may not have
  had: their digest covers exactly five act fields and they state that widening
  it to cover presentation would be a defect, since a new UI release would
  invalidate every prior approval. The GH-DEC-2026-008 cycle condition is mutual
  containment, so if their digest structurally cannot contain view_hash the
  containment is one-directional and no cycle arises. Not asserted as settling
  it — that cycle was found by two engines independently within hours and cost
  real work, and "the cycle cannot arise here" is the belief such failures
  punish. No design change made: layer.yaml still declares co-reference and
  nesting_forbidden as ruled, and approval-engine's recommendation is not
  adopted despite coming from the digest's owner, because a bilateral agreement
  produces agreement rather than an authority rule. Raised because the statute
  makes a disagreement a finding for gate-house rather than a choice. Carries a
  second smaller question: whether approver evidence should be human-only at the
  engine, since entries[].principal_type is auditable after the fact and stops
  nothing, and there is no upstream backstop for humans-bind-agents-draft. Full
  finding: docs/finding-r3-linkage-conflict.md.
state_hub_intake_id: "01a08b30-b7e7-70a6-9139-2eac8c1f6611"
```