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: 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: closed
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: >-
  Closed 2026-09-10. audit-core registered this source with every field as
  proposed — source informed-decision exact, tenants [tenant:platform], write
  true, read false, evidence_kind load-bearing, secret_policy redact — at
  c4016a7 as AUDIT-WP-0009-T11 / AUDIT-IN-0003, documented in their
  docs/informed-decision-source-registration.md. The entry is inert until the
  token exists, asserted by test rather than by reading. The two extra fields the
  ruling added (content_exists, custody) needed no schema change: data is stored
  verbatim into details.data and hash-chained, so a custodian cannot quietly
  retract the assertion that content existed. One class one source with distinct
  type values per class, because two senders would split one residual into two
  smaller-looking ones for a component whose defining property is that the actor
  and the evidence source are the same. Cadence accepted with the refinement that
  BOTH heartbeat and reconciliation scope per class, and with reconciliation
  applying to the high-volume class too since rate detects a stream stopping but
  never a stream missing the particular renders that mattered. One design
  consequence booked as PR-12: redact scans data, so the custody locator must be
  a stable non-secret identifier rather than a credentialed URL, or the existence
  declaration arrives without its pointer. Both controls are bounded and neither
  may be described as covering the compromised-emitter residual. Reconstructability
  is now written down on audit-core's side as well as ours. T08 unblocked.
  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: closed
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"
```


## INFD-IN-0005 — Reliable fresh authentication for timed reviews

```yaml
id: INFD-IN-0005
kind: intake
title: Reliable fresh authentication for timed reviews
status: open
origin: residual
origin_ref: SECRETS-WP-0010
priority: high
owner: informed-decision
repo: informed-decision
lane: blue
tags: [cross-repo, authentication]
created: '2026-09-16'
updated: '2026-09-16'
description: >-
  Coordinate with key-cape and the Authelia deployment owner to validate an
  upgrade supporting prompt=login/max_age, including changed ID-token claims,
  existing clients and rollback. Authelia 4.38 rejected even fresh sign-in in
  native logs; the review parameter change was rolled back (cbea539). Retain
  the 900-second review MFA requirement. Verify KeyCape preserves the original
  timestamp for reused authentication and records a new timestamp only after
  actual reauthentication; completeAuthorization currently copies a prior
  session timestamp even after MFA. Provide an actionable freshness error and
  prove the full browser path, not just redirect parameter forwarding.
  T03's three human approvals and key check subsequently completed; this is
  ongoing authentication reliability work, not an outstanding T03 execution.
state_hub_intake_id: "01a0c14e-f965-788f-8efb-4424f1f1ad08"
```


## INFD-IN-0006 — Is §3's layer vocabulary closed, and what is `surface`?

```yaml
id: INFD-IN-0006
kind: intake
title: Is section 3's layer vocabulary closed, and what is `surface`?
status: closed
origin: coordination
origin_ref: the-custodian/docs/assessments/2026-09-21-layer-declaration-boundaries.md
priority: medium
owner: gate-house
repo: informed-decision
lane: blue
tags:
- decision-request
- cross-repo
- conformance
created: '2026-09-21'
updated: '2026-09-21'
resolved_by: GH-DEC-2026-017
resolution: >-
  RULED 2026-09-21. The section 3 vocabulary is CLOSED and has four tokens —
  Taxonomy, Tooling, Engine, Staff — with comparison ASCII case-insensitive, so
  no repository is asked to re-spell anything. `surface` is not a layer and this
  repository's correct declaration is `layer: Staff, role: pep-shaped`, which
  the ruling notes this repository's own file already reasons from twice.
  Applied the same day in one commit, in INTENT.md and in layer.yaml, with no
  argument, exactly as pre-committed; the elimination reasoning that produced
  `surface` is kept as history in layer.yaml because the ruling's own reversal
  condition names it. The ruling also held that this repository was NEVER a
  section 11 non-conformance — section 11 binds estate-authored repositories IN
  section 4 and this repository has no catalog row, so a run that grades it is
  over-scoped — and it changed the declaration's FORM: INTENT.md governs,
  layer.yaml is a derived artifact that must be marked derived and agree, and a
  declaration carries no standard version, which removes the
  `standard_version: "0.7"` this repository had flagged. Two things spawn from
  it rather than close with it: INFD-IN-0007 (the section 3.4 fit, asked once
  more) and the section 4 catalog-row question, answered YES in
  docs/section-4-catalog-row.md.
description: >-
  This repository declares `layer: surface` in both INTENT.md frontmatter and
  layer.yaml. Section 3 of security-layer-model_v0.8.md enumerates four layers —
  Taxonomy, Tooling, Engines, Staff — and `surface` is not among them;
  flex-auth's conformance validator reads the vocabulary as closed and admits
  only {Staff, Engine, Tooling}, so this repository fails it on the value rather
  than on casing or on the B1 precedence question. Surfaced by the custodian's
  estate-wide sweep extending flex-auth's boundaries review (FLEX-WP-0030); it
  was never a finding raised against this repository directly. Two facts bound
  it: this repository is internally consistent — both files say `surface` in the
  same casing, so it is not part of the nine-repository B1 disagreement — and it
  has no section 4 catalog row, having declared ahead of being catalogued.
  `surface` denotes the presentation-and-binding tier: the runtime a human
  touches, where a decision rendered elsewhere is shown to a named person, that
  person's identity is bound to the act, and the evidence that the presentation
  happened is produced. It was chosen by elimination on 2026-09-09 (f6376dd),
  in this repository's own voice, because GH-DEC-2026-012 R1 ruled it out of
  Engine and left the layer to it to declare, and because each remaining section
  3 value is false of it — not Staff (deterministic by construction, and holding
  state audit-core depends on at runtime, which section 3.4 forbids Staff), not
  Tooling (persists nothing another layer reads), not Taxonomy (nothing but a
  runtime position). POSITION: `surface` names a real tier section 3 does not
  enumerate, the sharpest form being that a standing ruling plus a closed
  vocabulary would leave this repository no conforming declaration available —
  the section 9.1 defect applied to conformance that section 11 names. This
  repository does not claim the ruling must go its way: if gate-house rules the
  vocabulary closed and names which of the four values applies, both files
  change the same day without argument, and it asks only that such a ruling show
  how section 3's determinism cut reaches that value given GH-DEC-2026-012 R1,
  because the next repository in this position will reason from it. The declared
  value is deliberately UNCHANGED pending the ruling: changing it first would
  pre-empt gate-house and destroy the evidence of what was actually concluded.
  Scope narrowed the same day: railiance-master had already established, with
  fuller citations, that flex-auth's validator set is not section 3's enumeration
  — section 3 has four rows and `Taxonomy` is the first — and the custodian's
  record was corrected to say so, adding that section 3 writes `Engines` while
  section 4 types eight rows `Engine`. This repository reached the first half
  independently and does not re-argue it. The consequence is that `surface` is
  the only surveyed value outside section 3 itself and the only one needing this
  ruling; the two cases should not be ruled on together. One point carries over:
  if the set is ruled closed it should be written out as declaration values
  rather than inferred from table row labels. Full request:
  docs/gate-house-decision-request-layer-vocabulary.md.
state_hub_intake_id: "01a0c14f-17b6-72fb-8951-8c933bd05d6b"
```

## INFD-IN-0007 — How does section 3's determinism cut reach Staff for this repository?

```yaml
id: INFD-IN-0007
kind: intake
title: How does section 3's determinism cut reach Staff for this repository?
status: open
origin: residual
origin_ref: INFD-IN-0006
priority: low
owner: gate-house
repo: informed-decision
lane: blue
tags:
- decision-request
- cross-repo
- conformance
created: '2026-09-21'
updated: '2026-09-21'
blocks_nothing: true
description: >-
  GH-DEC-2026-017 closed INFD-IN-0006 and named the value: this repository is
  `layer: Staff, role: pep-shaped`, and that value is APPLIED — both files
  changed the day the ruling arrived, unconditionally, as pre-committed. This
  intake is not a reservation on it and nothing waits on it. INFD-IN-0006 asked
  one non-conditional question in two parts: WHICH value, and HOW section 3's
  determinism cut reaches it given GH-DEC-2026-012 R1. The first part is
  answered squarely. The second is answered by elimination — not an Engine per
  R1, and nothing else in the four is true, therefore Staff, with ops-mason and
  ops-warden as the precedent for Staff in the layer column and PEP-shaped in
  the role column. That gives the value and it does not reach the objection this
  repository actually raised, which was not about elimination but about fit:
  section 3.4 defines Staff as interactive and NON-deterministic, working
  through agentic capability, and says Staff repositories MUST NOT hold state
  that another layer depends on at runtime. This repository is deterministic by
  test (the same approval rendered to the same principal in the same role yields
  the same view_hash), forbids an agent from completing its protected act at all
  (AGENTS.md: humans bind, agents draft), and holds presentation evidence
  audit-core depends on. Section 3 makes determinism the primary cut and this
  repository falls on the deterministic side of it while being assigned the
  non-deterministic layer. ASK: that the answer be written down for the next
  repository in this position, which was the stated reason for asking the first
  time — either that section 3.4's prohibitions bind a catalogued Staff row
  differently than the elimination that reaches the layer, or that the cut is
  not what this repository read it to be, or that this is a real tension carried
  openly. Taking the section 4 row (docs/section-4-catalog-row.md) sharpens it,
  since a catalogued Staff row is measured against section 3.4 directly. This
  repository takes Staff either way and is not asking to be moved.
```