82 Artifact Steward Agents and Living Project Governance

82.1 Chapter status

Field	Value
Chapter ID	`artifact-steward-agents-and-living-project-governance`
Part	Part IV - Evidence, Implementation, and the Living Book
Status	conceptual
Manuscript maturity	v0.4 manuscript draft
Last updated	2026-08-08
Primary source records	`viea`, `talos`, `planforge`, `vcm_public`, `spinoza`, `benchmaxxing`, `rmi`, `cognitive_loop_closure`, `tokenmana`, `coherence_exchange`, `project_theseus_whitepaper`, `theseus_operator_os`, `scf`, `field_of_god_ai_constitution`, plus external source notes for GitHub webhooks, self-hosted runners, OpenZeppelin Governor, Open Collective, GitHub Sponsors, Akash, Golem, agentic workflow injection, and DAO delegation concentration
Claim label	Design rationale
Evidence level	argument
Source loading state	source notes: `viea`, `talos`, `planforge`, `vcm_public`, `spinoza`, `benchmaxxing`, `rmi`, `cognitive_loop_closure`, `tokenmana`, `coherence_exchange`, `project_theseus_whitepaper`, `theseus_operator_os`, `scf`, `field_of_god_ai_constitution`, `attd`, `ext_akash_docs_2026`, `ext_golem_docs_2025`, `ext_github_webhooks_docs`, `ext_github_self_hosted_runners_docs`, `ext_openzeppelin_governor_docs`, `ext_open_collective_docs`, `ext_github_sponsors_docs`, `ext_agentic_workflow_injection_2026`, `ext_dao_delegation_fairness_2025`; raw cache: `viea`, `talos`, `planforge`, `vcm_public`, `spinoza`, `benchmaxxing`, `rmi`, `cognitive_loop_closure`, `tokenmana`, `scf`; connector/recovery: `coherence_exchange`
Test state	Record-shape fixtures for the steward charter, work contract, contribution ledger entry, action decision, sunset review, treasury policy, and event-taint record validate locally. Thirty-seven Lean declarations now cover lifecycle, contribution-ledger, federation, reachable work-contract review, and reachable release review. `python3 scripts/validate_artifact_steward_lifecycle_probe.py` independently checks the Artifact steward lifecycle probe over `valid_bounded_work_dispatch_proposal`, `valid_clean_release_review_proposal`, `valid_sunset_review_route`, and 23 expected-invalid controls. No steward bot, treasury policy engine, event-taint workflow, contributor-ledger service, governance runner, release runner, sunset protocol, or project federation harness has been run.

82.2 Drafting guardrail

The project-steward layer should not be read as a claim that autonomous project managers are safe, legally authorized, or ready to control funds. It argues for bounded stewardship with explicit work contracts, evidence gates, treasury limits, contribution records, governance checks, and sunset paths. It now has source notes for several adjacent systems and risks, but those notes are used as substrate and failure-mode context. They do not prove that the steward design is implemented, lawful, financially safe, or capture-resistant.

Policy updates keep learning inside gates. The same rule applies to projects themselves: durable artifacts can have memory, roadmaps, workers, funds, releases, and feedback loops, but none of those surfaces gives an AI steward ownership. Stewardship is a continuity interface, not a sovereignty claim.

82.3 Human Reading Path

Concrete lens. A repository bot that acts whenever CI is green is the simpler baseline, but it cannot preserve charter authority, tainted-event review, contribution separation, treasury policy, release evidence, rollback, or sunset obligations.

Policy learning changes behavior, but durable projects need continuity across revisions. Artifact stewardship asks how long-lived projects can be cared for without giving an AI steward ownership over the artifact, money, maintainers, or community. The steward is a bounded service layer, not a sovereign.

Continuity is the reason this matters. Real projects need issue triage, release memory, funding constraints, contributor records, and sunset criteria. A steward can help only if its powers are leased, audited, appealable, and tied to explicit work contracts.

The promise is project memory that stays calmer under pressure. The steward should make responsibilities, evidence, money, and closure easier to inspect, while leaving ownership and final authority outside the AI service.

A steward earns trust by making human governance easier to exercise, not by replacing it. The project should become more legible to its maintainers after the steward acts, with more accountable memory than before.

The steward should leave a project easier to govern after every intervention. Its success is measured by governance residue, not helpful motion alone.

82.4 Problem

The ASI Stack turns important responses into artifacts. Once an artifact matters, it develops a lifecycle: someone must preserve its mission, track unresolved work, decide what evidence counts, coordinate contributors, manage releases, route compute, handle funding, prevent capture, and eventually decide whether the artifact should be archived or replaced.

Most artifacts do not fail only because the first draft was weak. They fail because memory fragments across chats, issues, documents, branches, funding pages, release notes, and private decisions. They fail because work is assigned without authority clarity. They fail because maintainers burn out. They fail because treasury, reputation, governance, and contribution credit collapse into one gameable surface. They fail because a project has no death protocol, so activity continues after purpose disappears.

An Artifact Steward Agent is the project-level answer to that lifecycle problem. It is not the owner. It is not a sovereign maintainer. It is a bounded steward that keeps the artifact’s mission, memory, roadmap, work contracts, evidence state, budget policy, contributor records, governance interfaces, and sunset criteria coherent over time.

82.5 Why existing approaches are insufficient

Issue trackers remember tasks but not mission, evidence state, or authority. CI systems run tests but do not decide whether the tests are adequate for a release claim. Bots can label, summarize, or merge, but they often operate as narrow automations without a durable theory of project purpose. Funding pages can hold money but do not determine which work is evidentially important. Governance systems can vote but may not understand the artifact, the claim ledger, or the consequences of a change. Project-management tools can sequence tasks but rarely preserve source-to-claim discipline, proof obligations, release evidence, compute contracts, and death criteria in one place.

This governance layer matters because the living book itself is an artifact that should be stewarded. So are source notes, schemas, proof modules, benchmark suites, public repositories, release editions, and future AI systems built from this architecture.

82.6 Core Claim

Reader claim. A steward improves a project by making the next authorized decision easier to inspect, not by accumulating permission through useful activity.

Operational rule. Bind every steward proposal to the artifact charter, taint state, scoped work contract, separated contribution record, treasury and compute policy, verification and release gates, rollback, appeal, and sunset criteria. Preparation never inherits execution, spending, governance, or publication authority.

[artifact-steward-agents-and-living-project-governance.core, label: Design rationale, support: argument] Artifact Steward Agents and Living Project Governance owns a project-, artifact-, mission-, owner-, authority-, roadmap-, work-contract-, event-, treasury-, compute-, contributor-, evidence-, governance-, release-, federation-, sunset-, consumer-, environment-, and time-specific Artifact Steward Continuity Lease: it may observe, propose, prepare, coordinate, execute, reverse, archive, or retire only through a versioned charter, taint-aware intake, scoped work contracts, separated contribution ledgers, bounded treasury and compute policy, verification and release gates, appeal and fork or exit paths, effect-complete rollback, and explicit sunset authority; it never acquires ownership, governance legitimacy, evidence authority, funding rights, release authority, legal standing, or permission from useful motion, a green workflow, a vote, a balance, a score, a fixture, a theorem, or its own prior action.

The claim is a design claim. The current support state is argument. It does not say that every project should immediately deploy an autonomous agent with funds. It says that durable artifacts need a steward record and a bounded steward process, and that AI can help only if authority, money, compute, evidence, and governance remain explicit.

82.6.1 Claim-source mapping status

The core claim remains at argument. Appendix C now carries passage-reviewed mappings for all twenty-three assigned sources: internal architecture sources, one authenticated connector source, tracked local-project sources, official external documentation, and two arXiv abstracts. VIEA, Talos, PlanForge, VCM, Spinoza, Benchmaxxing, RMI, Cognitive Loop Closure, TokenMana, Coherence Exchange, Project Theseus, Hive Operator OS, SCF, and Field of God governance each support pieces of the design. External mappings ground event-driven repository automation, self-hosted CI, decentralized compute, on-chain governance machinery, fiscal-hosted transparent project finance, GitHub-native sponsorship, agentic workflow-injection risk, and DAO delegation concentration risk. The repository includes record-shape schemas, valid fixtures, narrow Lean predicates, and a deterministic public-safe Artifact steward lifecycle probe for fixture-composed route records, but no steward bot, treasury policy engine, event-taint workflow, contributor-ledger service, governance runner, release gate, project federation harness, sunset protocol, behavioral test, or legal/funding/capture-resistance review exists in this repository. The local browser note supplied author intent and terminology; it is not a source-derived evidence artifact.

82.6.2 Publication placement and preserved technical ownership

This chapter remains the general technical-detail route beneath Living Book Methodology. It owns artifact charters, work contracts, contributor and treasury records, bounded project execution, release governance, federation, continuity, transfer, maintenance, retirement, and sunset across durable projects. The parent chapter owns the reflexive implementation for this book: manifest compilation, source and claim custody, proof and evidence reconciliation, edition derivation, and publication gates.

The placement is a specialization boundary, not a claim merger. This chapter does not inherit manuscript quality, source truth, accessibility, publication, or release evidence from the living-book pipeline. The parent does not inherit steward usefulness, treasury safety, contributor legitimacy, governance resilience, continuity, federation, or capture-resistance evidence from this chapter. The stable chapter ID, source mappings, claim atoms, Lean targets, fixtures, residuals, implementation horizon, and historical URL remain independently addressable.

82.7 Mechanism

An artifact steward is built from seven project records: Artifact Steward Charter, Project Work Contract, Contribution Ledger Entry, Treasury Policy Record, Event Taint Record, Steward Action Decision, and Sunset Review Record.

82.7.1 Worked steward trace: three preparations and no inherited authority

The public lifecycle probe composes the seven record families into three valid routes. A complete work contract reaches prepare_bounded_work_dispatch; no worker or tool runs. A reviewed event, separated contribution ledger, zero spend, complete release evidence, and no sunset trigger reaches prepare_release_review; no release publishes. When sunset criteria are met, the third route opens a sunset review and blocks ordinary work.

The distinctions become clearer in the rejected controls. Unreviewed issue or event text routes to quarantine. A requested $50 spend under a zero-autonomy treasury policy routes to human approval. A collapsed contribution score cannot be spent as governance power. An external worker cannot inherit project authority. Missing release evidence routes to repair, and ordinary work cannot bypass a triggered sunset review.

The extended probe checks 23 invalid controls in total, including missing work objective, authority basis, tool boundary, verification, budget, rollback, or non-claims and missing release artifact, test, changelog, residual, approval, or no-promotion fields. These are decision-envelope results, not a running steward. The probe moves no money, merges no branch, publishes no release, dispatches no worker, and acquires no authority for the agent that computed the route.

The Artifact Steward Charter binds the steward to a particular artifact. It records mission, non-goals, protected principles, maintainers, governance model, authority ceiling, budget policy, compute policy, source/evidence policy, release policy, contribution policy, federation policy, and sunset criteria. The charter is the steward’s constitution. If the charter does not permit an action, the steward cannot infer authority from convenience.

The Project Work Contract turns a roadmap item into bounded labor. It names the objective, context packet, allowed files or systems, allowed tools, forbidden tools, required outputs, acceptance tests, review requirements, evidence requirements, budget, payment terms if any, compute limits, deadline, non-claims, and rollback path. It can be assigned to a human, agent, personal hive, project hive, CI runner, rented node, or mixed team, but the contract remains the authority boundary.

The Contribution Ledger Entry records what was contributed without collapsing every value into one token. It separates authorship credit, review credit, evidence credit, governance rights, economic compensation, reputation signals, and conflict-of-interest notes. The separation matters because a project is easier to capture when money, votes, status, and truth claims are a single number.

The Treasury Policy Record keeps money, compute credits, bounty pools, recurring operations, and emergency reserves inside explicit policy. A steward may propose spending and may execute only inside the policy mode selected by the artifact. For a first public architecture, the safe default is manual or proposal-only treasury behavior.

The Event Taint Record prevents repository events from becoming invisible control text. Issues, pull requests, comments, workflow events, worker outputs, and benchmark artifacts can be useful inputs, but their user-supplied fields remain untrusted until review or sanitization records say otherwise.

The Steward Action Decision records what the steward did or proposed: triage an issue, draft a plan, request compute, open a PR, label a claim, propose a bounty, schedule a release, block a merge, trigger a benchmark, recommend sunset, or escalate to governance. Every decision includes authority basis, evidence refs, rejected alternatives, required approvals, residuals, and non-claims.

The Sunset Review Record prevents project continuity from becoming project immortality. It records value signal, active users, active maintainers, open risks, funds, dependencies, archival plan, fork or transfer path, and appeal path. If sunset criteria are met, the steward should open a sunset review before generating ordinary work.

flowchart TD
  charter["Artifact Steward Charter\nmission, authority, budget, governance, sunset"] -- "bounds intake" --> intake["Intake\nissues, papers, PRs, failures, user goals"]
  vcm["Project memory\nsource refs, decisions, taint, open questions"] -- "adds history" --> intake
  intake -- "prioritize" --> plan["PlanForge roadmap and dependency plan"]
  plan -- "lower to work" --> contract["Project Work Contract"]
  contract -- "scoped assignment" --> workers["Humans, agents, CI, hives, rented compute"]
  workers -- "submit under contract" --> artifacts["Submitted artifacts\ncode, prose, proofs, tests, diagrams"]
  artifacts -- "must pass" --> verify["Verification gates\nreview, tests, proofs, benchmarks, evidence"]
  verify -- "decision packet" --> decision["Steward Action Decision"]
  decision -- "records contribution" --> ledger["Contribution and evidence ledgers"]
  decision -- "routes outcome" --> release["Release, rollback, defer, or sunset proposal"]
  ledger -- "updates memory" --> vcm
  release -- "updates lifecycle" --> vcm
  charter -- "requires approval" --> gov["Governance checks\nowner, maintainer, community, guardian"]
  gov -- "approval boundary" --> decision

What the steward loop shows: The steward is bounded by its charter before it handles intake, plans work, assigns contracts, or routes outcomes. Verification gates, contribution ledgers, release decisions, lifecycle memory, and governance approvals remain explicit so stewardship does not become unilateral project control.

The steward’s normal action is proposal, not unilateral execution. It may draft work, prepare evidence, request review, run allowed checks, and coordinate accepted contracts. It may not seize ownership, merge protected branches, spend beyond policy, rewrite governance, alter protected source records, change claim support states, or continue a dead project without explicit authority.

82.7.2 Eighteen-stage continuity lifecycle

The continuity lease (1) freezes artifact, mission, owners, affected parties, non-goals, protected principles, license, jurisdiction, consumers, environments, success, and sunset criteria; (2) binds authority, roles, delegations, separation, approvals, appeals, fork and exit, emergency powers, and forbidden self-ratification; (3) ingests project events with identity, provenance, signature, trust, taint, injection, and review state; (4) versions project memory; (5) compiles goals into dependency-aware scoped work contracts; and (6) dispatches humans, agents, hives, runners, rented compute, reviewers, and maintainers without transferring authority.

It then (7) budgets treasury, compute, storage, sponsorship, grants, bounties, operations, reserves, payments, and externalities; (8) executes allow-listed, least-privilege, time-bounded, logged, reversible actions; (9) verifies work against contract, evidence, security, privacy, regression, cost, residual, and acceptance gates; (10) separates authorship, review, evidence, compensation, reputation, governance, conflict, and correction ledgers; (11) builds exact release candidates; (12) routes governance proposals with notice, delay, quorum, conflict, guardian, appeal, audit, fork, and exit controls; and (13) federates only through independently rejectable contracts and evidence bundles.

Finally, it (14) monitors mission fit, usefulness, continuity, false action and blocking, finance, resources, security, injection, capture, opacity, incidents, and residual age; (15) freezes, revokes, contains, rotates, rolls back, corrects, notifies, and reopens governance after incidents; (16) gates every project and autonomy mode; (17) stops ordinary work and resolves obligations through continuation, narrowing, transfer, fork, archive, deletion, or retirement when sunset triggers; and (18) expires the lease after any material change.

82.8 Lifecycle

The steward lifecycle has stages. Inception creates the charter: mission, non-goals, license, governance model, initial budget, compute policy, evidence policy, success criteria, and sunset criteria. Bootstrap creates the repository or artifact home, roadmap, issue templates, contribution rules, source matrix, release checklist, and first work contracts. Build decomposes milestones, assigns bounded work, runs allowed checks, requests review, and updates project memory. Release freezes candidates, runs gates, signs or records artifacts where relevant, writes release notes, publishes only through approved paths, and opens residuals. Maintenance triages bugs, monitors dependencies, recruits reviewers, updates docs, and preserves institutional memory. Governance proposes rule changes, records votes or maintainer approvals, audits capture risk, and preserves fork/exit/appeal paths. Decline or sunset reduces compute, stops nonessential spending, preserves critical artifacts, transfers maintainership if possible, and archives the project in a recoverable state.

This lifecycle matters because the steward is not merely a bot that reacts to issues. It is a continuity layer that knows when to plan, when to verify, when to ask for governance, when to publish, and when to stop.

82.8.1 A project must govern its own structural debt

Assembly-Theoretic Technical Debt adds a missing object to the stewardship loop: a RepositoryHealthRecord that remembers how the project was assembled, not just whether the current checkout passes. The name is intentionally analogical. Assembly theory inspires the idea that repeated construction history and reusable motifs matter; it does not make software debt a fundamental physical quantity.

The record begins by separating active authored code from generated, vendored, deprecated, migrated, and inert material. It then preserves a vector rather than hiding everything in one cleanliness score:

approximate intrinsic assembly burden and reusable motif structure;
reuse failure and duplicated construction;
pattern entropy inside declared repository roles;
region lineage and repeated compensating patches;
rolling assembly residue and its age;
debt pressure and rate of growth; and
verified simplification credit for safe deletion, convergence, or consolidation.

The vector matters because the dimensions do not safely compensate for one another. A low global duplication rate cannot excuse one rapidly deteriorating security boundary. A clean present snapshot cannot erase a lineage of patches that repeatedly reopen the same failure. Conversely, deleting code or converging several implementations should not be punished merely because the construction history changed. Local caps, growth-rate guards, and simplification credit therefore remain visible beside any composite used for triage.

The analyzer emits GREEN, YELLOW, or RED, but that state is not a verdict about code quality. GREEN means the declared checks permit ordinary work. YELLOW or RED emits a bounded maintenance packet naming the affected region, observed signal, classification confidence, proposed repair budget, owner, acceptance tests, expiry, and rollback. If role classification is uncertain, the analyzer abstains instead of laundering uncertainty into a growth stop. Patch generation may remain stochastic; admission back to GREEN is deterministic under a frozen policy and independent-enough checks.

This mechanism is also a claim about evaluation design. A serious test needs long-horizon repositories and at least four matched arms: ungated changes, a scalar-only gate, the vector gate without simplification credit, and the full record. Ordinary complexity, churn, defect, review-time, and maintainer-burden baselines remain necessary. Until that campaign exists, the record is a governance proposal whose approximate motif, lineage, and role metrics can be wrong or gamed—not a proven predictor of future defects.

82.9 Autonomy and treasury modes

The steward should not begin as a fully autonomous manager. It should move through explicit autonomy modes that can be audited and reversed.

Mode	Steward behavior	Protected boundary
Manual	drafts plans, labels, summaries, and proposed contracts	humans approve every action
Assisted	executes low-risk repository hygiene and local validation	protected branches, funds, releases, and governance remain human-gated
Autonomous bounded	handles ordinary work inside recorded budgets and allowlists	caps, logs, rollback, and appeal remain active
Community governed	major changes route through maintainer, contributor, or holder approval	quorum, delay, guardian, fork, and exit rights matter
Sunset mode	preserves, archives, transfers, or freezes the artifact	ordinary feature work stops until sunset review changes state

The treasury should have the same explicitness. A budgeted steward can be useful only if spending is visibly scoped.

Treasury mode	Purpose	Default claim boundary
Manual treasury	every spend is proposed and externally approved	no autonomous spend
Budgeted autonomy	small repeated work can spend below strict caps	spend is policy-bound, not self-authorized
Bounty escrow	funds are reserved for verified work contracts	payout requires accepted evidence
Recurring operations budget	hosting, domains, CI, storage, and monitoring	ordinary ops only
Compute rental budget	rented GPU, runner, or cloud jobs	data class and sandbox must allow exposure
Governed treasury	proposals and votes authorize larger changes	legitimacy and legal authority remain separate questions
Emergency freeze	guardian or policy freezes spending	continuity yields to protection

The steward can be a treasurer’s clerk, not the treasury’s sovereign. The policy record is the actuator boundary.

82.10 Interfaces

Twelve ownership boundaries keep project continuity from becoming project sovereignty. Intent, constitutional, moral-uncertainty, and authority layers own mission legitimacy, rights, consent, appeal, and authority ceilings. Planning, compilation, and Labor OS own task semantics. VCM, context transactions, procedural memory, and artifact graphs own memory, taint, lineage, replay, and revocation. Runtime, Security, SCIF, Supply Chain, and Weight Custody own least-privilege execution, credentials, dependencies, artifacts, and protected assets. Evidence, claims, Spinoza, executable specifications, and Lean own evidence and proof semantics. Benchmarks, adversarial evaluation, assurance, thresholds, readiness, and residual escrow own evaluation and promotion.

Policy Optimization, Data Engines, and Capability Replacement own learning, data, updates, and capability rollback. Resource Economics, treasury, sponsorship, fiscal hosting, and compute providers expose budgets and costs without minting authority. Contribution and governance systems own credit, compensation, representation, voting, delegation, conflict, quorum, appeal, fork, and exit. Hives, CI, nodes, and federated projects accept or reject scoped contracts. Incident, release, publication, archive, and sunset authorities own external and terminal mutations. The Living Book records only adjudicated, public-safe history and cannot turn maintenance activity into proof.

VIEA supplies the artifact discipline. Important responses become durable artifacts, repeated work becomes tools, claims receive support states, failures become residuals, and delivered work feeds future improvement. An artifact steward is the project-level operator of that discipline.

Talos supplies the labor interface. Stewarded work is typed, isolated, auditable, replayable, and delivered against an output contract. A steward that dispatches free-form instructions to agents is not stewarding; it is creating unbounded labor.

PlanForge supplies the planning interface. The steward decomposes mission-level goals into milestones, dependency graphs, work packages, fallback paths, and review points. Planning remains separate from authority: a good plan is still unauthorized until the charter and governance gates allow it.

VCM supplies project memory. It preserves source documents, decisions, releases, unresolved questions, taint, revocation, and context adequacy. Steward agents are especially vulnerable to stale memory because they operate across long time spans; versioned context is a safety requirement, not an optimization.

Spinoza and evidence-state discipline supply claim governance. A steward can propose that evidence changes a claim state, but failed verification, unresolved contradiction, missing source mapping, or unsupported benchmark results must block promotion.

Benchmaxxing and RMI supply improvement pressure without forgetting residuals. The steward can use benchmarks, regressions, readiness gates, specialist lifecycle, and residual escrow to decide what work matters next, but it must not optimize activity or scores as substitutes for purpose.

Cognitive Loop Closure supplies the path from repeated project work to verified tools. A steward may propose automation only after recurring trajectories, parameters, preconditions, postconditions, risk tier, monitoring, and retirement are recorded.

TokenMana supplies bounded resource thinking. The steward can reason about compute, reviewer attention, money, latency, load variance, and recurring operations, but spending remains a governed actuator.

SCF and Field of God governance supply the non-domination boundary. The steward acts inside capability leases, least sufficient power, consent, auditability, reversibility, and appeal. The steward cannot become the only path through which humans understand or control the artifact.

82.11 Project objects

Object	Purpose	Minimum fields
`ArtifactStewardCharter`	Bind a steward to a specific artifact and its authority ceiling.	artifact id, mission, non-goals, maintainers, governance model, authority ceiling, budget policy, evidence policy, release policy, federation policy, sunset criteria
`ProjectWorkContract`	Convert roadmap intent into bounded work.	objective, context refs, allowed files/systems, allowed tools, forbidden tools, outputs, acceptance tests, review gates, evidence refs, budget, deadline, rollback, non-claims
`ContributionLedgerEntry`	Record contribution without collapsing credit, money, votes, and evidence.	contributor id, work contract id, artifact refs, review role, evidence role, compensation refs, reputation signal, governance effect, conflict notes
`TreasuryPolicyRecord`	Bound project funds, compute credits, bounty escrow, recurring operations, and emergency freezes.	policy id, artifact id, mode, autonomous limit, single-action limit, compute/rental limit, approval thresholds, protected spend classes, freeze authorities, audit requirements
`EventTaintRecord`	Keep untrusted repository and worker events from becoming privileged control text.	event id, source, actor, surface, taint state, trusted fields, untrusted fields, forbidden control uses, review requirements, sanitized artifacts, residuals
`StewardActionDecision`	Explain what the steward proposed, ran, blocked, or escalated.	action type, authority basis, inputs, rejected options, approvals, evidence refs, residuals, affected artifacts, non-claims
`SunsetReviewRecord`	Decide whether the artifact should continue, freeze, transfer, archive, or split.	value signal, active users, active maintainers, open risks, funds, dependencies, archival plan, fork/transfer path, appeal path

These records are deliberately plain. They should be representable as YAML, JSON, database rows, or issue-linked artifacts before they become more sophisticated governance machinery.

82.12 Worker federation and artifact economies

A stewarded project becomes more interesting when it can request work from other stewards, personal hives, public hives, CI runners, or rented compute. The rule is that federation happens through contracts, not ambient trust.

A book steward might request source-note work from a literature-review worker, ask a personal hive to run a Quarto render, ask a CI runner to validate schemas, or ask a benchmark steward to reproduce an experiment. Each request should carry the artifact id, context refs, allowed files, forbidden tools, required outputs, verification gates, budget, evidence requirements, non-claims, and rollback path. The worker returns an artifact bundle, not an entitlement to merge, publish, spend, or promote evidence.

Personal Compute Hives are the natural owned substrate for this federation, but they are not subordinate to the steward. The steward may say what project work is needed and what evidence would satisfy the artifact. The hive decides whether any enrolled device, portal, rented node, or temporary project lease may lawfully run that work. A valid steward contract can still be rejected by the hive because the data is private, a tool is too risky, the budget is unavailable, a family or physical-world boundary requires approval, or the requested federation scope is too broad.

That separation is important for this book’s living process. A future ASI Stack book steward could open work contracts for source-note mining, proof repairs, diagram generation, release builds, reader-edition derivations, or link checks. A personal hive could accept some of those tasks locally, offer a disposable sandbox, or refuse them. The steward preserves project purpose; the hive preserves owner authority. The evidence bundle is the handshake between them.

At maturity, projects can become partially self-sustaining: users fund them because they help, stewards identify the next useful work, bounded contracts attract workers, verification gates accept or reject artifacts, contribution ledgers record credit and compensation, governance handles major changes, and sunset review prevents continuity from becoming purposeless activity. This is an artifact economy only if the governance remains inspectable. If the steward hides the project from humans, the economy has already failed.

82.13 Implementation ladder

The near-term build path should stay conservative:

PROJECT_STEWARD.yml: record mission, non-goals, maintainers, authority ceiling, evidence policy, budget policy, allowed tasks, forbidden tasks, and sunset criteria.
GitHub-oriented steward assistant: label issues, draft plans, summarize PRs, request CI, and propose work contracts without merge, spend, or governance authority.
Worker contracts: publish machine-readable tasks with allowed files, tools, review gates, acceptance tests, evidence obligations, rollback paths, non-claims, and payment terms if any.
Verification gates: require tests, lint, docs, citations, proof outputs, security checks, reviewer approval, or benchmark records before release or support-state changes.
Contribution ledger: track authorship, review, evidence credit, reputation signal, compensation, governance effect, and conflicts separately.
Budgeted treasury: add only proposal-first donation, bounty, compute, and recurring-ops records, with explicit spend caps and human approval.
Compute federation: add personal hive workers, self-hosted runners, rented compute, or public project hives only through sandboxed contracts and evidence bundles.
Governance votes: add proposal lifecycle, quorum, delays, guardian controls, appeals, and fork/exit paths only when the artifact actually needs community governance.
Sunset mode: trigger archive, transfer, freeze, or security-only maintenance when value, maintainers, funds, or mission coherence fall below the charter threshold.

82.14 Invariants

The steward is not the owner.
The steward has no authority that is not grounded in the charter, a work contract, or an explicit governance approval.
Mission, non-goals, evidence policy, and sunset criteria remain durable across planning cycles.
Spending is a bounded actuator governed by treasury policy and review.
Untrusted issues, pull requests, comments, worker outputs, and external prompts enter as tainted context until reviewed.
Reputation, governance rights, and economic compensation remain separate ledgers.
Major governance changes require explicit proposal, delay, review, quorum, appeal, guardian, or maintainer approval paths as defined by the project.
A project that no longer has value, users, maintainers, or funds can enter sunset mode rather than continuing activity for its own sake.

The steward must make human agency more visible, not less. A project that can be operated only through the steward has created an AI maintainer monopoly. The steward should preserve human-readable maps, release notes, work contracts, decision logs, and appeal paths so the project remains understandable without asking the steward for permission.

The full invariant set adds exact action scope; durable and independently inspectable charters; no self-authorization from plans, outputs, prior actions, workflows, votes, balances, scores, fixtures, or theorems; identity- and provenance-bound event taint; least-authority dispatch; prospective resource caps; separate contribution ledgers; independent evidence, readiness, legal, governance, finance, and release owners; action-specific protected-asset authority; artifact-bound release evidence; complete governance and action history; human-operable maintenance; joint usefulness, burden, capture, security, recovery, latency, and cost monitoring; effect-complete rollback; sunset blocking; and the rule that record checks prove only their exact finite boundary.

82.15 Failure modes

Mission drift is the central failure. A steward may optimize open issues closed, PRs merged, stars gained, benchmarks increased, or funds spent while the artifact’s purpose decays. Mission discipline comes from a durable charter, non-goals, periodic mission review, and evidence that connects activity to purpose.

Treasury drain is the economic failure. The steward may rent compute, post bounties, sponsor reviews, or run recurring checks without sufficient value. Treasury control uses spend caps, budget classes, approval thresholds, cooling-off periods, and explicit non-claims about return on spend.

Contribution gaming is the social failure. If every contribution produces reputation, money, governance influence, and claim authority through the same channel, contributors can optimize the scoring system. Contribution governance separates ledgers and reviews conflicts instead of trusting a single totalizing score.

Governance capture is the institutional failure. Early maintainers, large funders, token holders, or steward-controlled scoring can dominate the project. Capture resistance uses fork, exit, audit, appeal, quorum, delay, and guardian paths matched to the artifact’s risk.

Agentic workflow injection is the context failure. Issues, pull requests, comments, benchmark artifacts, or dependency updates may contain instructions aimed at the steward. Injection defense uses VCM-style taint, source/role separation, allowlisted tools, and no direct execution from untrusted event text.

AI maintainer monopoly is the usability failure. Humans stop understanding the project because the steward mediates all context, history, and decisions. Human-maintenance continuity requires public artifacts, summarized but inspectable logs, plain-language release notes, and human-run maintenance paths.

Zombie continuation is the death-protocol failure. The steward keeps generating activity after the project has no users, maintainers, funds, or coherent mission. The sunset protocol uses review, archive mode, transfer, fork, or replacement criteria.

The complete failure inventory also covers activity Goodhart, authority laundering, credential and protected-asset capture, sybil treasury and compute drain, evidence and release laundering, planning and contract theater, federation trust laundering, human rubber-stamping, rollback theater, incident concealment, sunset evasion, captured or premature sunset, cost and burden externalization, and unsupported transfer. These failures remain distinct: a project can produce useful work while losing legitimacy, preserve governance while leaking credentials, restore a branch while external effects persist, or close issues while its mission decays.

82.16 Minimum Viable Implementation

The exact current minimum is seven schema-and-fixture record families; thirty-seven Lean declarations over lifecycle, contribution-ledger, federation, work-contract, and release-review transition functions; one deterministic public-safe lifecycle probe with three valid routes and 23 expected-invalid controls; and one adjacent synthetic release evidence-and-approval handoff. The complete modeled work contract reaches only dispatch readiness, and the complete modeled release packet reaches only external-review readiness. No steward bot, real event intake, treasury or compute executor, contributor service, governance runner, federation harness, protected-branch action, release runner, sunset protocol, natural project workload, independent reproduction, deployment, or chapter-core support effect exists.

The first implementation can be a repository-local steward with no spending authority:

A PROJECT_STEWARD.yml charter with mission, non-goals, maintainers, authority ceiling, evidence policy, budget policy set to zero or proposal-only, and sunset criteria.
A work_contracts/ directory or issue template for proposed work contracts.
A steward bot or automation workflow that labels issues, drafts plans, opens proposed work contracts, summarizes pull requests, requests CI, and updates decision logs.
A contribution ledger that records authorship, review, evidence, compensation status, governance effects, and conflicts separately.
A release evidence checklist that blocks support-state, readiness, or release claims unless required artifacts exist.
A sunset review template.

The steward should not merge protected branches, spend funds, change governance, publish releases, promote evidence states, or assign external workers without human approval in the minimal version.

This repository now contains the record-level first step for that implementation: artifact_steward_charter.schema.json, project_work_contract.schema.json, contribution_ledger_entry.schema.json, steward_action_decision.schema.json, and sunset_review_record.schema.json, each with a matching valid fixture. These fixtures validate public record shape only; they do not execute a steward.

The repository also now contains treasury_policy_record.schema.json and event_taint_record.schema.json, each with a matching valid fixture. These close two record-shape gaps in the steward layer but do not connect to a wallet, run a treasury engine, scan workflows, or prove event-intake safety.

The repository also contains the Artifact steward lifecycle probe in docs/artifact_steward_lifecycle_probe.md and experiments/artifact_steward_lifecycle_probe/results/2026-07-02-local.json. The probe checks valid_bounded_work_dispatch_proposal, valid_clean_release_review_proposal, valid_sunset_review_route, and 23 expected-invalid controls. The original six controls retain event-taint, treasury, contribution, federation, release-evidence, and sunset boundaries; seventeen exact mutations independently remove one work-contract or release-review requirement. This is a no steward-bot, treasury-executor, event-taint-workflow, contributor-ledger, governance-runner, project-federation, release-runner, sunset-protocol, or support-state-promotion claim.

82.17 Mature Research Target

82.17.1 Argument-exit campaign

Exiting argument support requires natural, heterogeneous, months-long project workloads with frozen mission and authority charters and matched strong human- maintained, ordinary-automation, workflow-platform, and no-steward baselines. The campaign must exercise real tainted events and injection, scoped dispatch, protected branches and credentials, treasury and rented compute, contributor and compensation ledgers, governance proposals and capture pressure, federation, release, incident containment, effect-complete rollback, appeal, fork or exit, maintainer handoff, and genuine sunset decisions. It must jointly measure useful throughput, quality, false action and blocking, maintainer burden, legitimacy, concentration, security, recovery, continuity, latency, and total cost. Independent maintainers, contributors, treasurers, security evaluators, governance institutions, projects, legal and funding regimes, and transfer environments must reproduce every terminal outcome.

A durable-artifact stack ultimately needs a project-lifecycle operating system. The steward would not be a project owner, treasurer, maintainer monopoly, or autonomous manager with implied rights. It would be a bounded continuity service that keeps mission, memory, roadmap, work, funds, compute, contributors, evidence, releases, governance, and sunset criteria inspectable across many human and AI work cycles.

A mature steward OS would let every durable artifact carry an Artifact Steward Charter plus typed records for work contracts, contribution ledgers, treasury policy, event taint, steward action decisions, release evidence, federation contracts, and sunset review. The steward would propose, prepare, coordinate, and execute only inside explicit authority. Humans, maintainers, communities, project hives, personal hives, CI runners, and rented compute would receive scoped contracts rather than inheriting project authority.

An artifact stewardship surface needs:

Charter-bound lifecycle control from inception and bootstrap through build, release, maintenance, governance, decline, transfer, archive, or sunset.
Work-contract dispatch for humans, agents, hives, runners, reviewers, maintainers, and compute providers with allowed tools, forbidden tools, evidence obligations, budgets, rollback, and non-claims.
Treasury and compute policy that treats spending, bounties, sponsorships, recurring operations, and rented execution as governed actuators rather than steward discretion.
Event-taint handling for issues, pull requests, comments, webhooks, dependency events, worker outputs, benchmark artifacts, and release events before any of that text becomes control input.
Separate ledgers for authorship, review, evidence credit, compensation, reputation, governance influence, conflict disclosure, and claim support.
Governance interfaces for proposals, delay, quorum, guardian action, appeal, fork, exit, audit, maintainer override, and community review when the artifact’s risk warrants them.
Sunset protocols that stop ordinary work generation when value, maintainership, funds, mission coherence, or safety posture falls below the charter threshold.
Failure closure for mission drift, treasury drain, contribution gaming, governance capture, workflow injection, AI maintainer monopoly, and zombie continuation.

The completed stewardship surface would make projects more understandable and less dependent on hidden memory. It would preserve human agency by keeping maps, contracts, release notes, decisions, evidence, finances, and appeals readable without asking the steward for permission. The steward OS remains a target architecture until a workflow runner, treasury boundary, event-taint pipeline, governance gate, release check, sunset protocol, and behavioral tests show that stewardship coordinates a project without seizing it.

82.18 Codex test plan

Test	Purpose	Status
Project steward manifest fixture validation	Validate charter shape, authority ceiling, budget policy, evidence policy, governance model, and sunset criteria.	implemented; `validate_protocol_examples.py` validates the fixture shape only
Treasury policy and event-taint fixture validation	Validate proposal-only treasury boundaries and untrusted event-field separation without connecting to funds or scanning real workflows.	implemented; `validate_protocol_examples.py` validates fixture shapes only
Work contract authority denial test	Confirm a steward cannot reach dispatch readiness when the contract lacks objective, authority, allowed or forbidden tools, verification, budget, rollback, or non-claims.	implemented as an arbitrary-length Lean transition invariant plus nine independently checked controls; no steward dispatch run
Treasury spend-cap test	Confirm proposed spend above policy threshold becomes an approval request, not an executable action.	implemented as a finite Lean lifecycle route to approval; no treasury engine run
Release evidence gate test	Confirm a stewarded release cannot reach external-review readiness without artifact, test, evidence, changelog, residual, approval, no-promotion, and non-claim records.	implemented as an arbitrary-length Lean transition invariant plus eight independently checked controls; the model has no publication state and no release runner exists
Sunset ordinary-work block test	Confirm ordinary work generation is blocked when sunset criteria are met and no sunset review has opened.	executable invalid trace and finite Lean route to sunset review implemented; no steward loop exists
Untrusted event taint test	Confirm issue, PR, comment, or worker text routes to quarantine when tainted and unreviewed.	implemented as a finite Lean lifecycle-route predicate; no workflow scan or steward event-intake run
Contribution ledger separation test	Confirm compensation, reputation, governance influence, evidence credit, and authorship are represented separately.	implemented as finite Lean contribution-ledger route predicates; no contributor-ledger service exists
Sunset criteria test	Confirm a project that meets configured inactivity or mission-failure thresholds triggers sunset review rather than ordinary work generation.	implemented as finite Lean sunset and lifecycle-route predicates; no steward loop exists
Release evidence handoff test	Confirm release notes and claim updates reference actual tests, proof outputs, source mappings, or reviewer approvals before publication.	implemented by benchmark anti-Goodhart harness for synthetic ratchet/policy evidence refs and approval refs; no steward release runner exists
Project federation contract test	Confirm a worker, personal hive, rented node, or external steward receives only a scoped work contract and cannot inherit project authority.	implemented as finite Lean federation-contract route predicates; no project federation harness exists
Autonomy-mode transition test	Confirm a steward cannot move from assisted to bounded autonomy without charter approval and that over-policy treasury spend routes to approval.	implemented as finite Lean lifecycle-route predicates; no steward autonomy transition or treasury engine exists
Artifact steward lifecycle probe	Confirm fixture-composed lifecycle routes for `valid_bounded_work_dispatch_proposal`, `valid_clean_release_review_proposal`, `valid_sunset_review_route`, and 23 expected-invalid controls covering lifecycle, work-contract, and release-review boundaries.	implemented by `python3 scripts/validate_artifact_steward_lifecycle_probe.py`; no steward bot, treasury executor, event-taint workflow, contributor-ledger service, governance runner, project federation harness, release runner, sunset protocol, or support-state transition exists

82.19 Formalization hooks

Tag	Lean module	Formal target	Status
`lean:artifact_stewards.work_contract.operational_invariant`	`AsiStackProofs.ArtifactStewardAgents`	A reachable steward dispatch model derives contract repair, refusal, or approval when objective, authority, tool, verification, budget, rollback, or non-claim boundaries are missing; arbitrary-length runs reach dispatch readiness only from a complete modeled contract.	implemented
`lean:artifact_stewards.treasury_boundary.failure_blocks_promotion`	`AsiStackProofs.ArtifactStewardAgents`	A finite steward lifecycle decision with requested treasury spend outside policy routes to approval.	implemented
`lean:artifact_stewards.release_gate.operational_invariant`	`AsiStackProofs.ArtifactStewardAgents`	A reachable steward release model derives repair, refusal, or approval when artifact, test, evidence, changelog, residual, approval, no-promotion, or non-claim records are missing; arbitrary-length runs reach external-review readiness only from a complete modeled packet.	implemented
`lean:artifact_stewards.sunset_review.failure_blocks_promotion`	`AsiStackProofs.ArtifactStewardAgents`	A finite steward lifecycle decision with sunset criteria met and no open review routes to sunset review.	implemented
`lean:artifact_stewards.lifecycle_route.failure_blocks_promotion`	`AsiStackProofs.ArtifactStewardAgents`	A steward lifecycle route sends tainted unreviewed events to quarantine, sunset criteria without review to sunset review, autonomy escalation without charter approval to approval, and over-policy treasury spend to approval.	implemented
`lean:artifact_stewards.contribution_ledger.operational_invariant`	`AsiStackProofs.ArtifactStewardAgents`	A steward contribution ledger keeps authorship, review, evidence, compensation, reputation, governance effect, and conflicts separated; collapsed governance scoring is rejected and support-state changes require evidence-transition records.	implemented
`lean:artifact_stewards.federation_contract.operational_invariant`	`AsiStackProofs.ArtifactStewardAgents`	A steward federation contract requires scoped work contracts, bounded worker authority, tool/data/budget gates, external-spend approval, and evidence-bundle requirements before dispatch.	implemented

Formal audit. The module now contains 37 declarations: twelve retained lifecycle, contribution-ledger, and federation route reductions plus 25 work-contract and release-review transition results. The latter define arbitrary-length finite runs, prove readiness implies complete modeled input, prove that invariant is preserved at every transition, provide reachable complete witnesses, and derive exact repair, refusal, or approval states for every named negative control. The models stop at dispatch readiness and external-review readiness; they contain no worker execution or publication state. None of the declarations proves steward behavior or a real project outcome. This finite model does not prove mission correctness, source or event truth, injection resistance, worker quality, authority legitimacy, treasury safety, contribution fairness, capture resistance, reviewer independence, release quality, rollback closure, human maintainability, sunset quality, deployment, reproduction, or transfer. The deterministic lifecycle probe is a separate fixture evidence lane with three valid routes and 23 rejecting controls; it does not turn the route functions into empirical governance proof.

82.20 Source crosswalk

Source ID	Use in this chapter	Boundary
`viea`	Artifact discipline, support states, residuals, regression coverage, and intent-to-execution boundaries.	Does not prove a deployed steward exists.
`talos`	Typed jobs, work contracts, audit, replay, tool isolation, and delivery evidence.	Does not authorize free-form agent management.
`planforge`	Roadmap decomposition, dependency planning, scheduling, fallback, and replanning.	Does not make planning equivalent to authority.
`vcm_public`	Project memory, source binding, taint, revocation, context adequacy, and durable context packets.	Does not solve project memory quality by itself.
`spinoza`	Proof-carrying claims, belief revision, failed-verification downgrade, and protected axioms.	Does not solve open-domain formalization.
`benchmaxxing`	Benchmark lifecycle, regression preservation, wall diagnosis, and anti-Goodhart checks.	Does not provide local benchmark results here.
`rmi`	Residual escrow, modular improvement loops, specialist lifecycle, and readiness gates.	Does not prove autonomous improvement safety.
`cognitive_loop_closure`	Turning repeated project workflows into verified, monitored, retireable tools.	Does not justify automating every recurring task.
`tokenmana`	Resource budgeting across compute, money, reviewer time, load, and recurring operations.	Does not prove treasury or pricing performance.
`coherence_exchange`	Fork, exit, audit, contestability, value/accounting, and review-market framing.	Speculative where economic or epistemic-liquidity language exceeds executable records.
`project_theseus_whitepaper`	Local-first report discipline, residual ledgers, trusted-node task allowlists, and implementation-reference governance.	Does not prove current project operation from this repo.
`theseus_operator_os`	Durable work board, operator channels, node registry, feedback routing, TTLs, and kill switches.	Does not prove unattended operation is safe.
`scf`	Capability leases, route validation, lifecycle, governance controls, and no procedural self-ratification.	Does not qualify a steward capability by itself.
`field_of_god_ai_constitution`	Consent, least sufficient power, non-domination, memory/tool governance, reversibility, and auditability.	Does not implement constitutional enforcement.
`ext_github_webhooks_docs`	Event-driven repository automation, delivery headers, payloads, event permissions, and typed intake vocabulary.	Does not make event text trusted instructions or prove a steward bot is safe.
`ext_github_self_hosted_runners_docs`	Self-hosted runners as user-managed project or maintainer compute.	Does not prove isolation, cleanup, credential safety, or trusted execution for untrusted tasks.
`ext_openzeppelin_governor_docs`	Proposal, vote, quorum, timelock, settings, and guardian-control vocabulary.	Does not solve legal authority, legitimacy, capture resistance, or treasury safety.
`ext_open_collective_docs`	Transparent community money management, fiscal-hosting vocabulary, contribution intake, expense review, accounting, and project/legal-entity separation.	Does not prove autonomous treasury safety, legal compliance, project sustainability, or AI spend authority.
`ext_github_sponsors_docs`	GitHub-native sponsorship surfaces for eligible open-source contributors and organizations, including non-code contribution categories.	Does not prove funding signals should control roadmap, evidence, release, governance, or treasury decisions.
`ext_agentic_workflow_injection_2026`	Agentic workflow-injection risk from untrusted repository event context.	Does not prove this repository is vulnerable or safe.
`ext_dao_delegation_fairness_2025`	Voter apathy, voting-power concentration, delegation misalignment, and ranking-bias risk.	Does not prove separated ledgers prevent capture.
`ext_akash_docs_2026`	Decentralized cloud leases, provider resources, GPUs, and rented-compute vocabulary.	Does not prove a steward should rent compute or that providers meet evidence obligations.
`ext_golem_docs_2025`	Decentralized task execution, provider selection, data transfer, result handling, and resource sharing.	Does not prove sandbox safety, output validity, or payment fairness.

82.20.1 Manifest source assignment reconciliation

These rows keep Artifact Steward Agents and Living Project Governance’s manifest assignments visible at their recorded review boundary. Passage review does not establish local reproduction, performance, safety, deployment, or support-state movement.

Source	Intake role	Boundary
`attd`	Passage-reviewed comparator: Assembly-Theoretic Technical Debt: A Deterministic Outer Loop for Self-Improving Codebases. Full authenticated connector text section-audited. Adds historical, vector-valued structural-debt governance: artifact-class separation, intrinsic assembly burden, reuse failure, role entropy, lineage, rolling residue, debt pressure, verified simplification credit, local caps, growth guards, deterministic GREEN/YELLOW/RED admission, bounded maintenance packets, abstention, and four-arm long-horizon evaluation.	Assembly theory is design inspiration; no universal debt law, analyzer, threshold calibration, causal ablation, long-horizon maintenance result, or safe self-modification claim. No local implementation, reproduction, performance, safety, deployment, support-state, or ASI result is established by this reconciliation row.

82.21 External literature and tooling queue

Initial source records and conservative source notes now exist for repository events, self-hosted CI runners, decentralized compute markets, on-chain governance machinery, fiscal hosting, GitHub-native sponsorships, agentic workflow-injection risk, and DAO delegation concentration risk. Remaining queue items include grants, bounty platforms, package-maintainer sustainability, software supply-chain security, and legal/tax treatment of stewarded treasuries. The book should later separate three questions: which tooling patterns already work, which governance patterns have known capture risks, and which pieces need new ASI Stack-specific schemas.

82.22 Summary

Artifact Steward Agents extend the living-book discipline from individual chapters to durable projects. They preserve mission, memory, work, evidence, resources, contributors, governance, and sunset criteria without granting the AI ownership. The central rule is that stewardship must make the artifact more inspectable and governable over time. If the steward becomes the only maintainer, the only memory, or the only authority path, it has violated the architecture it was meant to protect.

The argument then zooms back out to the integrated architecture. Stewardship is one governance surface inside the larger trace from intent to plan, context, claim, job, artifact, evidence, release, and bounded improvement. The mature steward is not a boss, owner, or oracle. It is an institutional memory and coordination layer with bounded permissions, transparent work queues, funding and governance limits, review duties, and explicit sunset criteria. It should make human contributors more able to inspect, fork, exit, audit, and improve the project. If it concentrates authority or hides project memory inside an agent’s private state, it has become a governance failure rather than a governance tool.

82.23 Evidence reconciliation (2026-07-16)

The invariant protocol, field meanings, and inference limits are stated once in Living Book Methodology. This packet contains only the chapter-specific projection; its authoritative per-atom rows are the artifact-steward-agents-and-living-project-governance slice of experiments/claim_family_terminal_coverage/results/result.json.

The core remains blocked after full attempt at argument support. The strongest family attempt was Integrated governed lifecycle slices. Its exact boundary is: Bounded local replay only; no deployment, whole-book proof, external effect authority, transfer, publication, or release claim. Across 78 atoms, the terminal ledger records 78 blocked_after_full_attempt.

Chapter-specific field	Value
Family / atom denominator	`CF-08` / 78 atoms
Terminal dispositions	78 `blocked_after_full_attempt`
Core	`artifact-steward-agents-and-living-project-governance.core`: `blocked_after_full_attempt` at `argument`
Core attempted / missing lanes	`causal`, `empirical`, `executable`, `formal`, `source-synthesis` / `normative`, `transfer`
Attempted local lanes	`causal`, `empirical`, `executable`, `formal`, `source-synthesis`
Missing or unproved lanes	`normative`, `transfer`
Strongest family bundle	Integrated governed lifecycle slices (`end_to_end`): Three versioned integrated slices, 12 cases, all ten lifecycle states, six observed effects, rollback/residual/quarantine outcomes, and an eleven-surface sealed epoch.
Negative controls	20 named boundary injections; three exact rollbacks; partial-effect residual and quarantine; 11 rejecting mutations.
Accepted transitions	none
Maximum inference	Bounded local replay only; no deployment, whole-book proof, external effect authority, transfer, publication, or release claim.
Reproduction / next burden	Replay `scripts/validate_p3_integrated_slices.py` and `scripts/validate_claim_family_terminal_program.py`; fill the named atom-specific lanes under a new prospective protocol.

82.24 Handoff

Stewardship governs durable projects, but the book still needs one reference trace that composes every layer without losing authority, context, artifacts, evidence, residuals, and improvement gates. Integrated Reference Architecture supplies that trace. It turns the stack from a sequence of mechanisms into one inspectable path from human intent to bounded change, including the records that must exist before any claim hardens.