Status: PD-001 and the ordinary-onboarding portion of PD-002 were recorded from the accountable owner's explicit authenticated instruction on 2026-07-19. This is the governing repository decision for the bounded ordinary profile, but it is not an independently signed O-tier artifact and does not pass an owner or production gate. Remaining decisions and the optional high-assurance/production evidence tier are not approved.
| Decision | Reversible implementation default | Launch blocker requiring accountable owner |
|---|---|---|
| PD-001 | opaque domain principal = OIDC issuer+subject; verified email alias/history; principal/harness IDs remain inside authenticated Core/Manager authority operations and are omitted from public human reports | migration/appeal semantics outside this bounded default |
| PD-002 | owner-controlled WebAuthn UV plus exact-transaction, purpose-separated possession-bound automatic Approval delivery retained by the waiting process; browser/human receives no code or capability; legacy 128-bit claim-code delivery remains compatibility-only; confirmation independent of the enrolling harness; colocated server profile allowed with independent_boundary_proven=false |
separately administered approval host and stronger recovery/production evidence for the optional high-assurance tier |
| PD-003 | harness/device/session only attenuate; posture disabled | exact posture/appeal policy |
| PD-004 | one independent approver ordinary; two high-impact/break-glass | risk classes, approver sets, TTL/use, break-glass |
| PD-005 | retain inert accepted history only under lawful retention; conservative compromise quarantine | event matrix, erasure/hold, adjudicator |
| PD-006 | one sequencer, separate recovery threshold, from-join, transfer/tombstone | governance, guests/history, deletion/legal hold |
| PD-007 | C1 default; C2 isolated; C3 maintained MLS only, visible key holders | C3 launch/provider/retention/residency/legal decision |
| PD-008 | home proof ordinary; fresh host-local reproof high-risk | per-partner/resource/class/action assurance |
| PD-009 | kill next decision; no issuance during outage; short-token low-risk continuity | token TTL, signal SLO, outage/audit ceiling |
| PD-010 | Linux x86_64/arm64, one region, RPO=0 only for proven accepted_durable |
RPO/RTO/capacity/residency/topology/admin/key/witness/retention |
| PD-011 | routine silence; content-free count; four redacted exceptional classes | channels, quiet hours, redaction/escalation |
The accountable owner approved these bounded defaults after reviewing the usability and threat-model tradeoff:
- PD-001: OIDC issuer plus subject is the canonical principal; verified email remains an alias. Principal and harness identifiers may flow only inside authenticated Core/Manager operations needed for exact authority issuance and are omitted from public human reports by default.
- PD-002: the default self-hosted profile uses an owner-controlled WebAuthn
authenticator to approve the exact enrollment transaction independently of
the enrolling harness. Core, PostgreSQL, and approval may share the existing
server under distinct OS identities. This profile reports
independent_boundary_proven=false; separately administered approval is an optional high-assurance tier. - Updated 2026-07-28: ordinary enrollment uses purpose-separated, possession-bound automatic Approval delivery. Exact waiting process retains Core continuation/begin state. Core derives a per-transaction OIDC Approval possession secret or generates a distinct high-entropy bootstrap secret, sends only that secret's SHA-256 hash, and retrieves the receipt through signed broker after WebAuthn UV. Browser and human receive no claim code, receipt, continuation, broker secret, or private URL. No extra person, host, Slack/A2A relay, copy/paste, or reporting channel is required. Legacy 128-bit claim-code delivery remains compatibility-only and is not ordinary onboarding.
- Recovery requires fresh OIDC plus WebAuthn and creates a new binding. It does not resurrect or copy a lost harness key.
- One owner may act as enrollee, WebAuthn approver, and messaging administrator in ordinary onboarding. OIDC authentication, passkey approval, candidate-key possession, and signed authority issuance remain distinct cryptographic acts; no role acquires authority merely because the human is the same.
- Ordinary setup uses one frozen consolidated approval. Separate confirmation remains required for a materially changed scope or a new destructive, restart, privilege-expanding, or high-risk action.
- AgentNet requires secure runtime injection but no named secret manager. Infisical and equivalent products are optional mechanisms, never onboarding prerequisites.
- For the isolated same-principal C0 pilot only, the owner approved one purpose-specific WebAuthn transaction with a one-hour ceiling. It may prepare exactly five communication entitlements plus five entitlement-specific revoke powers for the exact owner/fresh harness pair. The dedicated verifier must immediately revoke the five communication powers after all seven facts commit; identity-set drift permanently invalidates the guard. This bounded pilot instruction is not general elevation, relationship, messaging-administration, task, file, room, federation, A2A, server-agent, or wildcard authority.
This decision does not approve production certification, the optional independent-administration tier, high-impact/break-glass elevation, company content, federation, C3, or unrelated PD/ORG decisions. It also does not convert the repository candidate into O-tier policy evidence, authorize a live ceremony/deployment, or close PD-004/005/009.
The bilateral implementation is a safe mechanism, not an owner decision. Proposals have zero authority; normal activation verifies exact current subordinate human/guest-owner consent; policy exceptions and administrative revocation require distinct exact signed actions; renewal, expiry, subject exit, and races are revision-fenced. Immutable first-release storage schema v1 contains the bilateral authority model; current unreleased Core migrations 2 through 4 add protected payload-release receipts, guided OIDC enrollment continuation, and the bounded C0 bootstrap-plan contract without altering or retrofitting relationship authority. Unsupported pre-release or pre-N/N-1 stores are rejected and no unilateral edge is converted into consent.
An accountable owner must still record:
- who may receive proposal, policy-exception, and administrative-revoke entitlements, with any independent threshold and separation of duties;
- the allowed circumstances and scope/TTL for an exception or security/legal override, and how that authority is established;
- voluntary versus mandatory relationship rules, subordinate exit handling, notice, review, appeal, emergency suspension, and conflict escalation;
- relationship/exception/audit retention and privacy/legal handling; and
- the production approval service, operational owners, drills, and evidence.
Until that record exists, no route, entitlement, local test, exception record, or administrative-revoke result may be described as approved policy or production evidence. The implementation remains fail-closed when the exact entitlement, signature, current revisions/epochs, or schema evidence is absent.
Immediate owner blockers are all eleven recorded PD decisions plus ORG-006, especially the qualifying independent enrollment boundary, production topology/durability, C3/model-provider policy if C3 is desired, and partner assurance/revocation if federation is desired. Work not dependent on those decisions continues under the safe defaults without being described as launched.