[EPIC] v0.8 — Asset Architecture (Genesis / Lifecycle / Binding / Tier / Assembly)

[devin-ai-integration]

Why this epic

.life v0.7 (epic #79) repositioned the project as the dual-standard ULTIMATE:
the file format spec + the runtime protocol spec for authorized digital-life
packages. This epic (v0.8) closes the architecture gaps that are blocking real
runtime implementations.

It introduces four asset-layer specs (Genesis / Lifecycle / Binding / Tier) and
a runtime-side update (5-stage assembly pipeline + Provider Registry) so a
.life package can be:

• traced from raw inputs to derived assets (Genesis)
• evolved, revoked, and frozen with cascade safety (Lifecycle)
• consumed by any compliant runtime with predictable behaviour (Binding)
• rated, ranked, and graceful-degraded by an auto-computed tier (Tier)
• launched in a verifiable, sandboxed, AND-gated way (Runtime / Assembly)

Background — architecture discussion (closed 2026-04-26)

All decisions were locked across four topics in a draft-and-iterate discussion.
The full record of decisions, rationale, and rejected alternatives lives in
docs/LIFE_ASSET_ARCHITECTURE.md (delivered by sub-issue #100).

Quick decision summary:

• Topic 1 — Genesis: D1=C virtual-asset base_model · D2=B hosted_api declared not blocking · D3=C graded reproducibility · D4=A fixed consent_scope enum · D5=B separate genesis/ directory.
• Topic 2 — Lifecycle: D1=D semver+content-hash · D2=C fork-allowed merge-forbidden · D3=B mark tainted · D4=C three-party-any memorial trigger + (a) read-only loadable + (c) executor extension + 7-day dispute period · D5=C soft re-consent reminder.
• Topic 3 — Binding: D1=C hybrid capability vocabulary · D2=C engine.strict · D4=C hybrid hard_constraints fail-close · D5=A binding+policy AND-gate · D3 replaced by tier system.
• Topic 3 — Tier system: 6 dimensions · weighted score 0–100 · 12 tiers (Schema D Cosmic Evolution: Quark → Singularity) · machine fields frozen, name/glyph in extensible appendix · fully public · replaces v0.7 verification_level.
• Topic 4 — Assembly: D1=C graded sandbox · D2=B (v0.8) + C (v1.0+) trusted issuer whitelist · D3=hybrid (cloud first-class, offline recommended, default per-user) · D4=C three-field surface · D5=C OS package manager bootstrap.

Sub-issues (in dependency order)

• v0.8: docs/LIFE_ASSET_ARCHITECTURE.md — overview doc #100 — docs/LIFE_ASSET_ARCHITECTURE.md — overview doc tying all four topics
• v0.8: docs/LIFE_GENESIS_SPEC.md + schemas/genesis.schema.json + sanity tests #101 — docs/LIFE_GENESIS_SPEC.md + schemas/genesis.schema.json + sanity tests
• v0.8: docs/LIFE_LIFECYCLE_SPEC.md + schemas/lifecycle.schema.json + sanity tests #102 — docs/LIFE_LIFECYCLE_SPEC.md + schemas/lifecycle.schema.json + sanity tests
• v0.8: docs/LIFE_BINDING_SPEC.md + schemas/binding.schema.json + sanity tests #103 — docs/LIFE_BINDING_SPEC.md + schemas/binding.schema.json + sanity tests
• v0.8: docs/LIFE_TIER_SPEC.md + life-package.schema.json::tier + Schema D appendix #104 — docs/LIFE_TIER_SPEC.md + life-package.schema.json::tier block + Schema D appendix
• v0.8: docs/LIFE_RUNTIME_STANDARD.md update — 5-stage assembly + Provider Registry #105 — docs/LIFE_RUNTIME_STANDARD.md update — 5-stage assembly + Provider Registry

Governance

• Each sub-issue → exactly one PR.
• PR body MUST contain Closes #<sub-issue> on its own line.
• New work uses separate branches per PR (post-.life: IMPLEMENTATION_STATUS + GAP_ANALYSIS reflect new ULTIMATE (#87) #99 instruction).
• This epic does NOT have a Closes line; it is closed by hand once all six
  sub-issues are merged.

Out of scope (deferred)

• Encrypted-mode bundled provider code (deferred to v1.0+ trusted issuer whitelist work)
• First runtime implementation (deferred to v0.9 — this epic is spec only)
• lifectl CLI / distribution (life://) protocol (deferred to v0.10+)
• OS file association + GUI launcher (deferred to v0.11+)