informed-decision/intakes/intakes.md

# 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: open
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-09'
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-09'
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"
```