Lifecycle Model

8 States

Critical Readiness Threshold (CRT)

The gate between Structured and Realizable. Four conditions must be met:

Intent - Answered

Object - Answered

Constraints - Answered

Expected Output - Answered

Additionally:

• Assumption Gate passed - no blocks with status "Assumed by AI" remain in the Canvas
• Specialized Readiness Blocks (pattern-specific) must have no blocking unknowns
• Supporting Blocks filled to a level sufficient for starting work

Four-Level Readiness Model

Universal Readiness Layer - the Critical Readiness Threshold (4 Critical Blocks Answered)

Assumption Gate - mandatory gate: every "Assumed by AI" block must be resolved

Portfolio Dependencies Gate - if depends_on relations exist, all blocking dependencies must be in Realizable or above state

Specialized Readiness Blocks - pattern-specific additional required fields

Portfolio Dependencies Gate

If an intenture has depends_on relations in Linked Intenture, Vergil must verify the state of blocking dependencies before Readiness Decision:

• All intenture that the current one depends on must be in Realizable or above state
• If any blocking dependency is not Realizable or above, transition is blocked
• Vergil shows blocking dependencies to human and proposes options
• Portfolio Dependencies Gate is optional: skipped if no depends_on relations exist

Lifecycle Transitions Table

Non-Linear Development

The lifecycle is not a waterfall. Allowed movements:

• Return to earlier states for re-explication
• Feedback loops from Evolving back to Structured (major change) or Realizable (minor update)
• Skip from Dream directly to Exploratory or even Explicated

Versioning Principle

At each significant transition, Vergil fixes a new Explication Record - a versioned snapshot of the current state of intenture. This ensures traceability of intent evolution and the ability to compare versions.

Realization Decisions

Lifecycle in Composition Hierarchy (introduced in v1.8)

With Composition, parent and children intentures have independent lifecycles with two hard constraints + two soft warnings (Vergil signals but does not block).

Hard constraints (block transitions):

Child cannot be Realizable+ if parent is in Dream/Exploratory.

Child cannot be Active (Realizable/In Realization/Evolving) if parent is Archived.

Soft warnings (Vergil signals):

Child reaches Explicated+ while parent is in Dream/Exploratory - "Designing sub-component of un-figured parent - parent's scope stable enough?"

Child reaches In Realization+ while parent is below Realizable - "Committing resources to part of un-ready parent - foundation work justified?"

Parent → Realizable (Value-coverage gate):

Parent's own Canvas passed CRT

For each must-have Value item there exists at least one child ≥ Structured contributing_to it

For each should-have Value item: either same as (2), or explicitly deferred with rationale

No constraint violations in blocking children

Archived cascade: when parent transitions → Archived:

Substantive (human via Vergil escalation): which children to preserve as standalone intentures (detach) or auto-archive with parent?

Operational (Vergil auto): remaining children cascade-archive with archived_due_to_parent reference.

Auto-transitions are executed by Vergil and don't require human approval except for substantive decisions.

Identity Operations (v1.8)

Beyond content version bumps, intenture may undergo identity operations: rename, move, detach, split, merge. See Syntax chapter for full description of authority and audit trail.

Rollback Procedure (introduced in v1.9, closes V4)

In addition to forward versioning, Intenture supports rollback - formal return to a previous Explication Record.

When rollback is allowed

• Failed realization - realization revealed the intent was formulated incorrectly (critical metric not achievable)
• Critical signal - new information contradicts current version (Evidence changed, Constraints infeasible)
• Substantive change reversal - human decided to undo a recent major change recognized as erroneous
• Conflict resolution - resolving inter-intenture conflict by rolling back one side to previous version

Rollback is forbidden for versions with significant realization work already performed on doversion deliverables (forward correction required instead).

Rollback Authority

Procedure (7 steps)

Identify target version - identify previous version N for rollback

Validation - check applicability + list downstream artifacts on the version being reverted

Authority check - determine decision-maker (Vergil or human)

Mark current as Reverted - current version N+1 gets status Reverted (rolled back to vN at YYYY-MM-DD)

Activate target - version N becomes current; artifact_version is set to N (not N+2)

Cascade rollback (optional) - analyze linked_artifacts compatibility

Audit log - record in metadata.change_log

Reverted status

• Versions in Reverted state are preserved for audit, not deleted
• Cannot be restored via direct rollback (only through forward version importing content)
• Rollback chains are forbidden (cannot rollback to a version already in Reverted state)

Lifecycle implication

After rollback Vergil re-evaluates Readiness (CRT + Assumption Gate + Portfolio Dependencies Gate) at target version and may downgrade lifecycle state if needed.

Entry Pattern Tracking (introduced in v1.9)

Applied Entry Pattern is recorded in metadata.entry_pattern of the intenture JSON artifact. Field is mandatory for intentures created in v1.9+.

Values: greenfield (from scratch) | from_concept (from conceptual documents) | from_artifacts | takeover (handover of realized work for further management via Intenture).

Vergil auto-detects Entry Pattern at first Explication Record creation. Can be corrected by human. Used to adapt AI Interpretation Protocol per pattern.