Raise INFD-IN-0001: layer placement and approver-UI ownership
File the gate-house decision request that gates INFD-WP-0001-T02, before any architecture is written, so the ruling constrains the design rather than being retrofitted to it. Three rulings requested: layer and role (proposed PEP-shaped, §6.4/companion §5); whether a presentation attestation also makes this a PIP or must reach consumers only through audit-core; and the relationship between view_hash and approval-engine's binding digest. The third is the highest risk and the reason this is filed first. Both digests claim to canonicalize "the binding" but cover different material — the approval digest exists without a human in the loop, view_hash covers the brief, packet, highlights, locale and UI release. Three candidate rulings are set out with what each costs; the proposal is distinct attestations with an explicit authority rule, but any of the three is implementable. The outcome to avoid is both shipping with no stated relationship. The self-dealing objection is argued against ourselves rather than left for review, and the residual is stated plainly: a compromised surface can present X and attest Y, structurally the same residual approval-engine names for adversarial omission at a compromised source. No claim is made to close it. 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
This commit is contained in:
parent
ebfa558eb0
commit
ebd35b59cf
2 changed files with 214 additions and 0 deletions
39
intakes/intakes.md
Normal file
39
intakes/intakes.md
Normal file
|
|
@ -0,0 +1,39 @@
|
|||
# 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: open
|
||||
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'
|
||||
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.
|
||||
```
|
||||
Loading…
Add table
Add a link
Reference in a new issue