In++ 2.0

Composition Hierarchy

Purpose

Composition Hierarchy (v1.8) is the mechanism for decomposing a large intenture into a parent-child hierarchy of separable sub-intentures with formal Constraint inheritance, Value aggregation, and Readiness roll-up.

Without Composition the Canvas remains flat. For simple intents this works. For large projects (dozens of interrelated sub-intents with different readiness, resources, deadlines) a flat Canvas becomes unreadable - for both humans and AI. Composition closes Vulnerability V1 (Canvas scalability).

Nature of Composition

Composition is a separate primitive in the Meta-Model, not a special type of Inter-intenture Relation:

Inter-intenture Relations (graph, V2)	Composition (tree, V1)
Between independent, peer intentures	Between parent and its parts
Each side retains full identity	Child is part of parent's substance
No Constraints / Value inheritance	Inheritance flow parent → child
No Readiness aggregation	Aggregation flow child → parent (via Value coverage)
depends_on cycles technically expressible	contains cycles mathematically forbidden - tree

Both formalisms coexist. The same child can simultaneously have composition.parent (hierarchy) and linked_intenture[].depends_on to cross-tree intentures (graph).

Two Constraint Inheritance Patterns

Each Constraint type has a fixed inheritance pattern.

Pattern A: Inherit & Restrict

Parent's constraint inherits as baseline. Child may only tighten (raise quality, narrow scope, earlier deadline, add safety rule).

Applies to types: [safety], [legal], [quality], [coordination], [scope], [timeline].

For [timeline] a special form of Restrict applies: Capped. Parent deadline = upper bound for each child.

Pattern B: Pool & Allocate

Constraint is a shared resource at parent. Parent declares total. Children get allocated shares via allocated_from. Sum(child allocations) ≤ parent total.

Applies to types: [budget], [resource].

Inheritance Override Governance

Child can replace an inherited constraint via inheritance_override block.

Constraint type	Override allowed?
[safety]	Never. Forbidden regardless of approver.
[legal]	Never. Same.
[scope]	Never. Narrowing only.
[timeline]	Never override. Only tightening (earlier within parent_upper_bound).
[quality]	Yes, with rationale + approved_by (Vergil for operational, human for substantive).
[coordination]	Yes, similarly.
[budget], [resource]	N/A. Pool & Allocate, not override.

Substantive impact: override changes user-facing deliverable or Value - requires human approval. Technical override - Vergil approves on its own.

Value Coverage and Readiness Roll-up

Parent is ready for Realizable when:

Parent's own Canvas passed CRT

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

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

Nice-to-have Values - no requirements

No constraint violations in blocking children

A child is automatically considered blocking if: blocking_for_parent: true explicitly set, OR child is the only one with contributes_to_parent_value for at least one must-have Value of parent.

Lifecycle in Hierarchy

Parent and children have independent lifecycles. See Lifecycle chapter for details.

Hard constraints (block transitions):

Child not Realizable+ if parent in Dream/Exploratory

Child not Active if parent Archived

Soft warnings (Vergil signals):

Child Explicated+ while parent in Dream/Exploratory

Child In Realization+ while parent below Realizable

Auto-transitions executed by Vergil. Human approval required only for substantive decisions (Archived cascade, Split, Merge, Move between sub-trees).

Separability Principle

Not everything that is "part of" parent should be a separate sub-intenture. Each sub-intenture costs implementation overhead (own Canvas, lifecycle, constraint inheritance, validation). This cost should be paid only for separable units.

Rule: Child S of parent P qualifies as a valid sub-intenture if and only if S is separable - has identity as a separable product/result. If S is not separable - it's a Canvas block of parent.

4 Separability Tests

Test	What it checks	PASS criterion
1. Independent Intent	Does S have its own Intent?	Intent is self-contained, not described via "implement part of P's Intent"
2. Discrete Expected Output	Does S have an identifiable deliverable?	Deliverable is separable (tested, deployed separately)
3. Own Value	Does S have own Value item?	Value targets actor with benefit not reducible to "parent's value was delivered". Multiple actors with distinct benefits = strong PASS.
4. Reparent-survivable	Would S's identity survive under different parent?	S would make sense under a different parent or standalone

Verdict scale

4/4 PASS → clean Sub-intenture
0-1/4 PASS → clean Canvas block (collapse into parent's Canvas)
2-3/4 PASS → Borderline. Vergil signals human with decision factors

Depth Recommendation

Composition tree depth is not hard-limited, but ≤ 3 levels is recommended:

Depth 0: root intenture
Depth 1: major sub-systems
Depth 2: components

Deeper - signal of over-decomposition. Vergil shows WARN at composition.depth > 3.

Canonical JSON Composition

composition:
  role: root | parent | leaf
  parent: parent-intenture-slug | null
  contains:
    - child-slug-1
    - child-slug-2
  depth: 0
  blocking_for_parent: computed | true | false

Principle

Composition is the mechanism for decomposing intent. Every decision to add a sub-intenture is a substantive decision by the human. Vergil assists through separability check, complexity signaling, and automation of operational transitions.

Next:Vergil