Docs Council Execution P0 Phase1 Execution Authorization

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

Life in Days Phase 1 — P0 execution authorization addendum

• Effective: 2026-08-14
• Authority source: Direct Product Owner activation of the committed Phase 1 P0-to-production Goal
• Status: Active, subject to every evidence, privacy, recovery, and non-delegable gate below
• Deployment state: Unknown — private read authority pending

Decision

The activated Goal supersedes historical statements that all implementation is categorically unauthorized or that G1 shared-understanding confirmation is the current universal execution stop. It authorizes local/public work, fictional/synthetic implementation and evaluation, normal Git/GitHub delivery flow, and separately scoped live actions only after their specific gates pass.

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 gate passes, the five-role execution council may make routine, reversible R0–R8 readiness, implementation, scoped deployment, repair, rollback, and promotion decisions without adding a generic owner walkthrough at every release. Decisions must follow source precedence, use the smallest reversible action, and be recorded with evidence.

The council may create/edit code, tests, migrations, app-scoped deployment configuration, documents, P0- evidence, generators, projections, branches, commits, pull requests, issues/Project metadata, workbook, Wiki, and RUNNING_LOG.md within the activated Goal's rules. 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:

• P0 execution governance and control remediation under existing task PC-001;
• task-specific Product, Architecture, Design, QA, Delivery, and Council dossier authoring for all 58 existing issues;
• R4/System Health contract correction;
• local generator, verification, Project-view containment, Wiki, CI, and public-safety hardening;
• fictional/synthetic R0 design and host-independent preparation after the P0 package passes.

Held now:

• private-system reads or mutations;
• host-specific architecture freeze;
• R0 implementation/release acceptance and deployment;
• 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.