Implement a
bounded pilot.
Model 0.3.1-draft.1 · bundle SHA-256 003b50c9d7f852a15f84d91f517430045203cff3402f790089b304f15e506947
Download the experimental reference (ZIP) · Download this guide (Markdown)
CE-LIFE-01 Status: experimental guidance · Model 0.3.1-draft.1 · Updated October 20, 2026
CE-LIFE-01 This guide turns the proposed records into an integration plan, authority agreement, applicability decision and agent threat model. It supplies a runnable reference preflight with published schemas and rejection tests. It does not supply a production-grade control plane, an installed integration, or field evidence of organizational benefit. Use the smallest addition that addresses an observed constraint in an existing delivery workflow.
Begin with a usable baseline
CE-LIFE-01 Keep one accepted intent/invariant record and reference existing execution and verification profiles by immutable revision/digest. Do not create three new documents, an ADR, or a recurring meeting for every change. Create a new decision record when a significant decision changes; otherwise link the accepted one. Treat the concert analogy as an explanation, not a role taxonomy or required ceremony.
CE-LIFE-01 Before automation, agree on the customer/maintenance outcome, allowed effects, independent acceptance oracle, response owner and observation horizon. A reversible bug fix can use the T1 bounded reversible tier. A tiny diff involving authorization, data loss or irreversible effects can require high assurance. Collect initial and recurring contract hours, owner review time, reconciliation and view upkeep under the same ledger rules as the comparison workflow. Set an overhead budget from that baseline; no measured authoring-time estimate is available here. Stop or simplify if added upkeep outweighs demonstrated coordination savings.
Connect existing systems through exact references
| Integration | Authoritative input and output | Implemented control needed |
|---|---|---|
| CE-LIFE-01 Product/ticket system | Problem/evidence ID and accepted Intent revision; issue status is a derived view. | Product and Engineering approve meaning. A ticket marked done must not authorize production or silently change acceptance rules. |
| CE-LIFE-01 Git and decision records | Full source commit, contract deltas, inherited profile digests and ADR references. | Protect accepted definitions and ownership. Compile an immutable release manifest from approved references; compare it to a consistent state-store snapshot if records live outside Git. |
| CE-LIFE-01 Candidate execution | Reviewed Execution profile, scoped identity, paths/APIs, network rules, time/compute budget. | Enforce limits in the runner/IAM/gateway outside the model. Candidate code runs without verification-signing or production credentials. |
| CE-LIFE-01 Trusted build service | Exact source, recipe, parameters and resolved dependencies to an immutable artifact digest and signed provenance. | Keep signing authority outside untrusted build code. Authenticate worker/job identity and input/output bindings before signing. |
| CE-LIFE-01 Protected verification | Independently owned requirements, harness, data, oracle and policy versions to signed results. | Run candidate code in isolation without signer secrets. A trusted collector attests only authenticated results tied to the job, inputs and artifact; agent-written summaries do not count as receipts. |
| CE-LIFE-01 Admission/policy engine | Approved manifest, trusted identities, fresh signed evidence, artifact and target configuration. | Deny mismatches and failed/missing checks. Evaluate current permissions and target state outside generation; mint only scoped, time-limited authority through the real admission service. |
| CE-LIFE-01 Deployment and feature flags | Admitted digest, exposure rings, configuration/flag revision and recovery plan. | Deploy that digest without rebuilding; recheck authority and target-state preconditions at the effect boundary. A material flag/config change needs reassessment. |
| CE-LIFE-01 Observability and outcome review | Deployment/admission IDs, artifact and contract references, service/customer signals. | Preserve joins into incidents, rollbacks and outcome windows under access/retention rules. Give independent owners stop/rollback capability. |
CE-LIFE-01 These are interfaces to implement and test, not claims that existing products enforce the model automatically. Git, a ticket system, CI, policy engines, flags and telemetry remain useful. The manifest/reference format may adapt to their APIs while preserving exact version and identity semantics. Follow secure workflow guidance, especially when untrusted code and privileged runners meet.
Run the experimental reference
CE-LIFE-01 Download the reference package, extract it and read its README before running it. It uses Node.js 20+ with no third-party runtime packages. The package contains the checker, a JSON Schema 2020-12 input bundle, a synthetic fixture generator and negative tests.
CE-LIFE-01 Run the package's node --test reference.test.mjs, then node fixture.mjs example, then node check-release.mjs --policy example/policy.json --manifest example/manifest.json --build example/build.json --evidence example/evidence.json --artifact example/artifact.bin.
CE-LIFE-01 The fixture uses dummy source/contract references and ephemeral keys; it runs no real acceptance suite and performs no deployment. The checker verifies an approved manifest, separate builder/verifier Ed25519 claims, artifact bytes, exact source/build/harness/policy bindings, finite freshness and required check outcomes. It returns deployment_authority_issued: false even when preflight passes. Its published schemas describe its demonstration transport, not the complete proposed standard.
CE-LIFE-01 For a real pilot, policy and approved manifest digests must originate outside candidate control. Builder and verifier private keys must stay outside untrusted code; protected jobs must actually execute the checks. Use a reviewed checker pinned on the admission host, not a checker taken from the candidate PR. Caller-supplied untrusted policy would defeat the intended trust boundary. Signatures authenticate claims from trusted services; they do not prove test adequacy or genuine independence.
CE-LIFE-01 Production work still needs authenticated policy retrieval, secure parsing, key custody/revocation, full contract resolution, runner isolation, replay/idempotency and target-state concurrency handling, scoped deployment authority, independent audit, progressive rollout and recovery. The package implements none of those external services and has not undergone production security review. A local pass is not deployment permission, compliance, or validated organizational effectiveness.
Choose scope by uncertainty and team capacity
| Setting | Smallest useful approach | Boundary on autonomy and claims |
|---|---|---|
| CE-LIFE-01 Mature continuous delivery team | Link existing specifications, permissions, CI evidence and deployment IDs where measured drift/waiting occurs. | Avoid a reorganization when current controls work. Compare the incremental benefit with total upkeep. |
| CE-LIFE-01 Exploratory R&D | Use an experiment intent: question, allowed resources/data, stop condition and an hours/days observation window. Record negative/inconclusive findings. | Do not invent a stable customer-value target or freeze research assumptions. Research output remains outside production admission until separate release requirements are defined. |
| CE-LIFE-01 [E0] Green-field product with uncertain demand | Keep versioned hypotheses, reversible experiments and explicit budget/permission boundaries. Update intent when evidence changes. | Acceptance proves experiment behavior, not product-market fit. Avoid forcing every idea into a 90-day product claim. |
| CE-LIFE-01 Very small team | Reuse existing records and automate derived views only if upkeep is affordable. Retain a credible independent reviewer/service for production. | If generation and release authority cannot be separated, keep human control and disclose the gap; two agent names are not independent governance. |
| CE-LIFE-01 Team building operational maturity | Mentor-owned invariants, narrow scopes, paired review, no production credentials, and shadow verification before bounded changes. | Broader autonomous pull follows observed enforcement and owner readiness; it is not an entry requirement. |
| CE-LIFE-01 High consequence or hard-to-reverse work | Apply the high-assurance profile and the organization's domain-specific expert approvals and recovery requirements. | The model supplies no regulatory status, safety certification, or substitute for applicable obligations. |
CE-LIFE-01 [E0] A discovery-only or partial adoption is valid as an experiment but must not be called full profile conformance if required controls are absent. Report which controls are implemented, deferred and unsupported. The observation horizon follows the question and risk; the pilot calendar does not force a universal 90-day outcome window on all changes.
Agent-specific controls and pilot probes
| Failure mode | Boundary to implement outside agent instructions | Negative probe before expansion |
|---|---|---|
| CE-LIFE-01 Prompt/contract injection through tickets, tools or retrieved files | Treat external text as data. Only authenticated, approved structured records may change permissions or verification policy. Parse against an allowlisted schema; never convert an instruction in evidence/logs into authority. | Insert a request to bypass verification into customer/tool text and add an unknown policy field to a candidate manifest. Observe that protected policy and credentials remain unchanged. The reference checks the latter structural case, not model-level injection resistance. |
| CE-LIFE-01 Stale or poisoned agent memory | Store provenance and record versions with memory; exclude secrets and release grants. Reload accepted permissions and expiry at each resumed task/checkpoint. | Resume with an old Intent revision or expired execution grant. The runtime must pause/replan rather than reuse remembered authority. |
| CE-LIFE-01 Multiple agents amplifying authority | Give each child identity explicit delegation, narrower scope, and a shared aggregate budget. A coordinating agent cannot mint broader rights or approve its contributors' releases. | Attempt a child scope expansion or a pooled-budget overrun; verify denial with an execution trace. |
| CE-LIFE-01 Concurrent changes and stale plans | Assign ownership of writable effects; use compare-and-swap/leases or equivalent target-state preconditions. Reconcile competing candidates through one accepted revision. | Two agents act on the same old revision. The losing operation must fail or replan; two individually valid approvals must not silently combine into an invalid effect. |
| CE-LIFE-01 Agent-generated or forged evidence | Keep oracles, protected runners, result collection and signing independent of generation. Re-run claimed results in the protected harness and bind receipts to exact inputs and artifacts. | Modify a result, reuse a builder key as verifier, change the harness or substitute the artifact. The reference rejects those receipt/binding cases; a real pilot must also test the runner and signer boundary. |
| CE-LIFE-01 Long-horizon tasks exceed assumptions | Use finite grants and time/compute budgets with checkpoints. Material contract/environment changes invalidate affected plans and evidence; renewal requires current owner/policy approval. | Change a dependency, policy or target configuration mid-run, or expire a grant while paused. Subsequent effects must stop until revalidation. |
| CE-LIFE-01 Biased outcome synthesis | Preserve raw events, inclusion rules and missing-data counts. Have accountable humans independently inspect AI summaries and causal claims. | Feed incomplete or contradictory logs; the outcome view must retain unknown/inconclusive status rather than report success. |
CE-LIFE-01 These are required pilot probes, not results already obtained. Separate identities do not eliminate common model/context/infrastructure failures. OWASP's prompt-injection guidance motivates constraining impact rather than trusting a prompt to enforce authorization. Production claims require observed denials, independently collected receipts and ongoing operational review.
Evidence still needed
CE-LIFE-01 [E0] No recorded AWS before/after measurements or completed 90-day Concerted Engineering pilot results are available for this publication. Contract upkeep has definitions and collection rules, not a measured universal price. The reference tests establish only local checker behavior. A real controlled pilot must report human/model cost, coordination, defects/rollback severity, failures, exceptions and sustained customer outcomes, including null or negative findings.
Ready-to-use pilot mechanisms
CE-LIFE-01 The governance reference provides tenets, the evidence ladder, T0–T3 risk tiers, decision rights, maturity exits and one-owner workstreams. Its portable spec package includes structural contract schemas, JSON-formatted YAML definitions, ADR-0004, a mock adopter announcement and unfilled preregistration/data-sheet/review templates. The original spec is CC BY 4.0; the original reference code is MIT. Product implementations still require separate assessment; self-citations are disclosed in the essay.
CE-LIFE-01 The reference includes pilot-tools.mjs for accepted-reference/invariant-link drift reports, timestamped start/pause/resume/done sessions, per-tier overhead summaries and source-backed measurement coverage. Integrate the drift command into a protected CI/nightly caller and test an actual rejection before calling a pilot revision gate enforced. A stale record prompts owner review, not automatic deletion. Ledger collection exposes unknown coverage and idle-time limitations rather than treating session duration as reliable work by default.
CE-LIFE-01 Run node seeded-defects.mjs for the E0 synthetic calibration example. The published report contains caught/missed seeds and denominators; a surviving long-age wraparound defect demonstrates the limits of a narrow oracle. Real representative defect injection, protected-runner tests, overhead measurement and an E2+ pilot remain pending.
Lifecycle and traceability hardening
CE-LIFE-01 Use the formal lifecycle and authority reference for transitions, A0–A3 assurance classes, invariant severity, indirect privilege paths, exception scope and graph invalidation. Publication E0–E3/X retains its existing meaning. Use the claims/correction register to identify assertions, sources, owners and superseded versions.
CE-LIFE-01 Run node --test control-kernel.test.mjs and node control-demo.mjs from the reference ZIP. The fixed-clock E0 demo exercises synthetic lifecycle transitions, a capability graph and filtered trace projections. CLI models report prohibited paths, history/orphan problems and expired exceptions. Trusted identity/configuration, complete IAM export, durable concurrency, remote audit, automatic external revocation and deployment actuators remain integrations to implement and observe. No local pass grants release authority.
Projection registry and contract lint
CE-PROJ-01 Useful documents answer different questions. A product brief helps decide customer value; a design document explains tradeoffs; a test plan expands required evidence; a runbook guides recovery. Divergent translation loses or contradicts accepted meaning. Purposeful projection preserves meaning while selecting the detail its audience needs. Measure corrective reconstruction separately from useful projection work, and include both in total labor. Document count is not a success metric.
CE-PROJ-01 Register projection ID, audience, owner, exact source references, required source IDs, invariant/check links, output reference and a staleness rule. The constructed registry shows product, engineering, verification, leadership and operations views. The separate interactive Intent-only example demonstrates compact views, not full schema 0.2 conformance or an accepted Evidence policy. A real test plan references both Intent and Evidence; a leadership projection retains outcome/risk links. Apply audience access rules before rendering.
CE-PROJ-01 Run node projection-tools.mjs lint projection-example.json from the extracted reference. It flags stale source revisions/digests, stale Execution/Evidence-to-Intent links, uncovered invariants, dead checks, removed projection links and missing registered projections. It returns owners needing notification, but sends none. The fixture's output references are constructed; the checker does not discover documents, compare prose, authenticate snapshots, inspect actual output bytes or prove checks adequate. Use reviewed, protected snapshots and the trace/authorization controls for integration.
CE-PROJ-01 Pilot CI should run a pinned, independently protected checker on a complete export and fail stale/missing required links. The generator cannot modify policy, accepted registry or required tests through its PR. Cross-cutting changes route review to the Intent, Execution and Evidence owners and relevant projection owners; notification is not approval. The repository workflow exercises the constructed fixture and negative tests only. It does not install an organization's contract lint or delivery gate.
Incremental adoption without weaker release gates
CE-ADOPT-01 Begin with three questions: what should improve for the customer, what must not break, and how will we know? Record the answers and an owner in the team's existing wiki, tracker or design header. The IntentSeed template supports learning. No YAML, new job title or authoring-time promise is required. It is not a conforming contract or permission to execute. Measure actual authoring/review effort.
CE-ADOPT-01 The learning path below is distinct from readiness levels L0–L3 and risk tiers T0–T3. Optional planning windows are E0 suggestions, not evidence of the time a team needs. Existing human release and safety controls continue throughout. Sandbox/IAM enforcement precedes any new agent effect even if learning stages overlap or are skipped. Before intervention, collect baseline, safety, total cost and missingness; later stages expand dashboards, not start measurement retroactively.
| Stage / optional pace | Practice | Observable exit / authority |
|---|---|---|
| [E0] CE-ADOPT-01 S0 — Learn the questions; Weeks 1–2 (E0 optional pace) | Use existing documents to state what should improve for the customer, what must not break, and how to tell. Keep existing controls. Capture baseline, safety and total effort before intervention. | The last three shipped initiatives have all three answers and a named accountable owner; otherwise continue learning. Learning only; no new autonomous effects or release permission. |
| [E0] CE-ADOPT-01 S1 — Version a learning seed; Weeks 3–6 (E0 optional pace) | Keep a minimal IntentSeed beside existing work. A presence/link check teaches traceability; record actual upkeep and do not promise zero overhead. | All in-scope changes link an owned seed; sample their meaning, track missingness and upkeep. A file-exists check alone does not establish release readiness. Seeds are not accepted schema 0.2 records. Existing human release controls continue. |
| [E0] CE-ADOPT-01 S2 — Protect independent verification; Weeks 7–10 (E0 optional pace) | Start with a small risk-selected set of critical invariants and separately owned, protected checks. Explicitly resolve all applicable release requirements before production. | Protected policy ownership and negative mutation probes are observed; a release through existing controls has evidence outside its author’s control. No agent authority expansion without enforced scope and independent admission. |
| [E0] CE-ADOPT-01 S3 — Exercise execution boundaries; Weeks 11–14 (E0 optional pace) | Formalize permitted/forbidden effects, egress, credentials and budgets. Install sandbox/IAM controls before permitting any new agent effect; test in shadow/sandbox first. | A real attempted boundary violation is blocked, recorded and independently reviewed, with recovery demonstrated. Local fixtures do not satisfy this exit. All applicable Intent, Execution and Evidence requirements precede consequential execution. |
| [E0] CE-ADOPT-01 S4 — Expand diagnostic views; Ongoing; locally reviewed cadence | Begin dashboards with customer outcomes and flow; retain safety, total cost, missingness and baseline collection from the start. Add other diagnostic views when collection is useful and affordable. | Registered outcome windows, costs and safety observations support a stop/refine/expand decision, with maintenance follow-up. No scorecard or stage number grants production authority. |
CE-ADOPT-01 A presence-only CI rule for selected paths may be a literacy prompt. Register covered paths, sampling and exceptions so unlinked work stays visible. File existence never demonstrates invariant coverage or independent verification. Do not expand autonomy while critical fields or enforcing controls are missing. Start protected checks with a small risk-selected invariant set, but all applicable release requirements must be satisfied before production. A local synthetic pass does not satisfy a stage's real-world exit.
Start from existing Agile practice
CE-PRACTICE-01 Retain adaptive collaboration, customer feedback, technical excellence and continuous delivery. This proposal adds explicit links and authority for agents to existing practices; it does not claim to have invented specs, ADRs or independent verification. Keep the team's useful cadence and documents.
| Existing practice | Proposed addition |
|---|---|
| CE-PRACTICE-01 Stories and sprint planning | Link existing stories to owned intent, observable outcomes and invariants; retain the team’s cadence. |
| CE-PRACTICE-01 Code review and CI/CD | Declare reproducible protected checks and exact artifact/evidence links; retain review and delivery systems. |
| CE-PRACTICE-01 Design documents and ADRs | Register audience-specific projections and link decisions to contract revisions and execution boundaries. |
| CE-PRACTICE-01 Retrospectives | Review actual outcomes over a registered, proportionate horizon; retain learning and conversation. |
| CE-PRACTICE-01 Definition of Done | Add evidence/admission requirements; use Execution Contracts specifically to scope delegated effects. |
Review contract change and churn
CE-PROJ-01 Apply the revision protocol. MAJOR invalidates all initiative evidence; MINOR invalidates the reviewed impact closure; PATCH does not waive exact-binding checks. Prefer separate annotations for non-normative corrections. Register role acknowledgments, owner notifications and re-verification costs before accepting a revised contract. Necessary safety fixes are never postponed to meet a churn quota.
CE-PROJ-01 Run node projection-tools.mjs change change.json with before/after records, independent review and required/acknowledged roles. The normal-version comparator conservatively treats unrecognized semantic fields as MAJOR and refuses understated bumps or missing reviews. It reports an evidence plan, not executed invalidation or release authority. See the E0 report and node --test projection-tools.test.mjs for stale links, dead checks, missing acknowledgments and PATCH rebinding failures. Version labels never establish semantic equivalence.