Docs Council Execution P0 Phase1 Execution Authorization

Canonical source: docs/council/execution/P0-PHASE1-EXECUTION-AUTHORIZATION.md · Snapshot commit: 6b8b70b72148

Life in Days Phase 1 — P0 execution authorization addendum

• Effective: 2026-08-15
• Authority source: Direct Product Owner activation of the published bounded P0/R0 Gold Goal from clean exact main 2dc4d05cdeca8cb9aeacf393076f6c6f946ff62b
• Status: Stage 0 local/public control-plane repair active; no R0 stage or private action currently authorized
• Deployment state: Unknown — private read authority pending

Decision

The historical broad P0-to-production activation is superseded. The bounded Goal owns exactly eight P0/R0 task records and freezes all 50 R1-R10 tasks. Its one-time Stage 0 bootstrap authority permits the reviewed local/public control-plane and factual repair under existing issue PC-001; it does not authorize an R0 action. Later local fictional/synthetic candidate preparation requires task-bound Gate A, and any execution or acceptance requires a separate immutable stage to pass Gate B and the guarded exact-main runtime.

This addendum changes authority, not evidence. Every truthful statement that application implementation, testing, host qualification, deployment, restore, accessibility conformance, production verification, or launch has not occurred remains in force until direct evidence changes it.

Delegated routine authority

When every named stage gate passes, the five-role execution council may make routine, reversible R0 preparation, implementation, repair, rollback, and promotion decisions within the bounded Goal. R1-R10 remain frozen and unavailable. Decisions must follow source precedence, use the smallest reversible action, and be recorded with evidence.

During Stage 0 the council may create/edit only the named control tools, tests, governing documents, P0- evidence, generators, projections, workflow, branch/PR records, workbook, Wiki, and append-only log mechanism required by the Gold Goal. No product/prototype behavior, private target, authentic content, live delivery-state transition, or R1-R10 task surface is authorized. Normal PR review and required checks remain mandatory; no direct push to main, force-push, history rewrite, destructive cleanup, or unrelated mutation is authorized.

Non-delegable human acts

Only the Product Owner or a separately recorded human authority may:

• authenticate through MFA/OAuth or supply a secret through an approved private path;
• accept legal/provider terms, create a paid account, or approve a material processor/privacy/spend choice;
• authorize authentic journal/photo/voice content or first authentic-memory admission;
• perform authentic-photo UAT through a private non-AI path;
• make R9 subjective owner UAT decisions;
• establish and control both independent off-server recovery-key copies and perform their human Recovery Ceremony steps;
• issue final R9 Proceed, Hold, or Roll back; or
• authorize a triggered R10 irreversible stage or retirement of the last local authoritative copy.

Ephemeral synthetic keys may test mechanics, but do not satisfy owner key custody or the launch Recovery Ceremony.

Private deployment-authority gate

Before any connection to or read/write action against a private host, provider account, tunnel/DNS configuration, backup repository, or production resource, a private access-controlled record must identify:

1. exact target and account;
2. permitted Life in Days resources/actions;
3. approved change window;
4. co-resident workload approvals or an explicit none-required statement;
5. private raw-evidence location;
6. rollback decision-maker and reachable rollback inputs; and
7. credential/secret owners and rotation boundary.

The public repository records only an opaque evidence ID, scope class, reviewer, window, and pass/fail. An authenticated session alone proves access, not authority. Until the record exists, the entire private lane remains Unknown — private read authority pending.

Source precedence

1. Direct Product Owner decisions, including the activated Goal and the later P0 naming instruction.
2. Governing PRD for product behavior and stable requirement IDs.
3. UX specification for interaction behavior.
4. Current Phase 1 Council decision record.
5. Applicable release PRD/PID, implementation plan, and manifest within their disciplines.
6. Discovery, research, historical trackers/councils, and prototypes as provenance.

Conflicts are recorded and corrected; the council does not choose a convenient lower-authority source silently.

P0 artifact naming

Every newly created document or artifact uses a basename beginning P0-. Existing canonical filenames, generator outputs, stable IDs, frozen evidence, and RUNNING_LOG.md are grandfathered. They may be edited under change control but are not renamed or duplicated solely to add the prefix.

Current authorized work

Authorized now:

• the exact Stage 0 control repair and factual reconciliation under existing task PC-001;
• the permanent 50-task R1-R10 freeze verifier and deterministic aggregate-only provenance checks;
• Gate A/Gate B, successor-review, append-only log, staged-runner, delivery-transition, Wiki, CI, generator, workbook, and public-safety controls using only fictional/synthetic test fixtures;
• normal branch, exact-head PR review, expected-head merge, and local/public projection/Wiki reconciliation after every required review passes.

Held now:

• private-system reads or mutations;
• host-specific architecture freeze;
• every R0 preparation stage until its own Gate A proposal passes;
• every R0 execution/acceptance stage until its later exact Gate B record and guarded runtime pass;
• R0 implementation/release acceptance and deployment outside those exact stages;
• all R1-R10 work;
• substantive work on any task whose dossier is not council-approved at the exact reviewed revision;
• authentic-content admission;
• provider/spend/terms changes; and
• production or recovery claims.

The current authoritative distribution is 58 Incomplete; 45 Hold + 13 Historical non-authorizing; 0 Ready; 0 execution-allowed. This Stage 0 candidate begins with only the non-authorizing successor-review genesis; empty preparationReviews and stageApprovals arrays; and empty production action, module, and outcome-verifier maps. A later preparation-only publication remains inert. A later implementation candidate may add a reviewed definition/module while still non-executable. Only a separately published stage record that binds the exact definition/module and passes the full exact-main Gate B runtime can authorize that one stage. The current successor-review state is derived from the immutable record history by node tools/P0-successor-control-review.mjs; this document does not freeze a later publication result into mutable prose.