The VCDesign core
The core in six parts
To implement Value Continuity on the side of judgment and responsibility, VCDesign specifies six things: Δ, responsibility, boundary, decision, declaration and metrics.
Norms: core.yaml, policies.yaml, metrics.yaml, axioms.yaml. Reading aids: implementation.md, glossary.md.
1. The six parts
| Part | What VCDesign specifies |
|---|---|
| Δ | The gap from the declared expectation (premises and value), with polarity: Negative Δ is not propagated; Positive Δ is made propagable |
| Responsibility | Owner, human final decider, custody across handovers (gate starts responsibility; tenure sustains it) |
| Boundary | Losses are stopped (containment), basis passes (basis_flow), conclusions are revalidated |
| Decision | Only the six words — Proceed, Expand, Limit, Reframe, Defer, Retire — through one judgment gate |
| Declaration | Per case: what remains (with a holder), spread signals, max loss, reversibility, dependencies |
| Metrics | Seventeen core metrics ordered by the five principles: keep, find, close, try, pass on |
2. The basic flow (PDΔD)
A chapter is a unit of responsibility placement that keeps a value alive; a case is a responsibility-bearing item handled inside a chapter. A case moves in this order (core.yaml flow).
3. Δ
Δ is an implementation concept. VCDesign takes the general meaning given canonically (the gap between the declared expectation and what happened) and fixes its baseline, polarity and handling. The expectation is declared as precondition (including the conditions of the chapter and responsibility placement) and value_intent, and both directions are observed against the same baseline.
When a gap is a Δ
- Observation proceeds in three levels:
observation→candidate→confirmed - Transient noise is not a Δ; the deviation must be sustained
- It must affect responsibility (for a Negative Δ, which responsibility placement breaks; for a Positive Δ, who holds it)
Polarity
| Negative Δ | Positive Δ | |
|---|---|---|
| Propagation | Not propagated | Made propagable. Spreading it is the decision Expand; it never spreads by itself |
| Handling | Localize, mitigate, close if needed | Observe, interpret, make reusable |
| Route | Boundary guard (unknown stops and escalates) → containment → decision | Observation → interpretation against value_intent → recorded with a holder. Expand to spread it |
| Stopped? | Subject to stopping | Observing and holding are never stopped. If Expand lacks its preconditions, it is the Expand that is stopped |
- A mixed observation is split into separate Positive and Negative Deltas
- A Δ without a recorded polarity is treated as negative
A confirmed Δ stays under responsibility until a decision closes it
A confirmed Δ must not remain ownerless or unresolved; holding does not lapse between confirmation and decision. An undefined point at design time (a definition gap) is also a Δ, closed by a decision before implementation starts (core.yaml closure_loop).
4. Responsibility
Every chapter and case has an owner (the current holder) and a final decider (the human who closes decisions). The final decider is always human. The supervisor is the final convergence point that prevents responsibility from disappearing.
Gate and tenure
| Gate — responsibility as a point | Tenure — responsibility as a line | |
|---|---|---|
| Question | Is this correct now? | Who keeps holding this? |
| Where | The moment of approval | Every day after approval: handovers, unattended operation, time |
| Role | Starts responsibility | Sustains responsibility |
Tenure is recorded with four fields:
custody_chain— the append-only record of handovers, including whether the successor confirmed they can re-derive the judgmentre_derivation_basis— the basis from which a successor can re-derive the judgmentreview_triggers— what change forces a review (events, not the calendar)last_reaffirmed— the record that a named human confirmed the decision is still valid
The more autonomous the operation, the further people step out of the loop, so the need for tenure grows rather than shrinks. The capacity to hold responsibility is finite: overloading one actor degrades every judgment they hold (axiom A5).
5. Boundary
A boundary is a point where a crossing is checked, losses are stopped, basis is passed on, and upstream conclusions are re-checked (boundary-pattern.yaml).
| Function | Applies to | Default |
|---|---|---|
| guard | The crossing itself | Verdict pass / deny / unknown. Unknown stops and escalates; it is never treated as pass |
| containment | Failures and commands | Do not pass (deny) |
| basis_flow | Basis and what remains | Pass (allow) |
| revalidation | Upstream conclusions | Not inherited; re-checked |
The boundary pattern also covers who keeps holding the boundary definition itself (tenure), and declaring identity, boundary and authority before crossing into another organization or agent (external_crossing, the Continuity Claim Protocol).
A guard verdict (pass / deny / unknown) checks each crossing; it is not the decision that closes a case's Δ. Repeated deny or unknown, or any verdict that affects responsibility, is observed as a Δ and closed with one of the six decisions.
Which "boundary"?
- Responsibility boundary (B1–B17) — a type of point where responsibility must be made explicit (taxonomy.md)
- Boundary structure — the pattern that implements it: guard, tenure, containment, basis_flow, revalidation
- Failure domain — the compartment outside which a failure must not propagate; its edge need not coincide with a responsibility boundary
- Continuous ↔ discrete boundary — where AI inference meets real-world execution (AI extension)
6. Decision
A human closes each Δ with one of Proceed / Expand / Limit / Reframe / Defer / Retire. No other decision vocabulary is used. Every decision passes one judgment gate, and Expand and Limit are recorded as updates of the declaration. See Decisions.
7. Declaration
Each case declares the following at its start (fields are defined in schema_case.yaml).
| Side | Field | Meaning |
|---|---|---|
| Upside (keep, find) | value_intent | The value the case aims to create |
residual_assets | What remains when work, owner or technology changes (records, standards, basis, connections, capabilities). Each needs a holder; without one it does not remain. A case with none is a point improvement | |
spread_signals | Signs of wide spread (cheaper second use, unsolicited pull, output used as input, more value per connection). Declared as expected, recorded as observed or unexpected, and evaluated separately from average_outcome | |
| Downside (close, try) | blast_radius | The pre-declared ceiling of failure: scope (range) and max_loss (size). Undeclared means high impact |
reversibility | Whether the decision can be withdrawn, reduced or corrected. An irreversible case must declare max_loss | |
failure_domain | The compartment outside which a failure must not propagate | |
depends_on | Dependencies, used to see concentration on the same dependency | |
| Continuity (keep, pass on) | owner | The current holder |
custody_chain | The append-only record of handovers | |
re_derivation_basis | The basis from which a successor can re-derive the judgment | |
review_triggers | What change forces a review |
8. Metrics
Metrics are instruments for observing Δ and inputs to decisions; they never replace decisions. The core metrics are ordered by the five principles (metrics.yaml).
| Principle | Metric | Detects |
|---|---|---|
| Keep | owner_missing | A chapter's owner is absent, unassigned or not acting |
custody_gap | The owner changed without a handover record, or holding began without confirming re-derivation | |
one_shot_improvement | An improvement was voided by a change of work, owner or technology and nothing remained | |
positive_delta_without_holder | A Positive Δ was observed but nobody holds it | |
| Find | spread_signal_observed | A declared or undeclared spread signal was observed (detection of a Positive Δ) |
success_without_spread_signal | The average outcome was met but none of the declared signals appeared | |
reuse_cost_trend | The trend of the cost of applying what remained somewhere else | |
| Close | precondition_broken | A declared condition, prohibition or acceptance condition was broken |
blast_radius_undeclared | An irreversible or costly decision was executed or approved without a declared max loss | |
blast_radius_exceeded | The actual loss or impact exceeded the declared ceiling | |
transitive_trust | An upstream conclusion became a downstream premise without being re-checked at the boundary | |
concentration | Many cases or boundaries share the same dependency or the same judgment path | |
| Try | expand_beyond_recovery | Widening outpaces the capability to recover or withdraw |
halt_readiness | Whether halt orders, human override and safe retreat can actually be triggered | |
| Pass on | decision_without_basis | A decision has no recorded basis, or only the conclusion was handed on |
review_trigger_missing | A long-lived case has no event-driven review triggers | |
| Operations | stagnation | Cases that should be closed are stuck (unresolved Δ, overdue Defer, unfinished Retire) |
Metrics that detect a Positive Δ never force a halt or blocking; their highest level is warning.
9. Implementation by principle
How VCDesign implements each canonical principle (from implementation.md §2).
| Principle | VCDesign mechanism | Metrics |
|---|---|---|
| Keep | residual_assets with holders. Gate and tenure: custody_chain, re_derivation_basis, review_triggers, last_reaffirmed | owner_missing, custody_gap, one_shot_improvement, positive_delta_without_holder |
| Find | A Positive Δ is not an anomaly: observe → interpret → make reusable with a holder. spread_signals are declared at the start and evaluated apart from the average outcome. An upside whose cause is unknown is marked unknown by the guard and never justifies widening | spread_signal_observed, success_without_spread_signal, reuse_cost_trend |
| Close | Without predicting the distribution, cut amplification with the four mechanisms below. A fatal downside halts regardless of whether an owner exists (judgment_gate.hard_stops) | precondition_broken, blast_radius_undeclared, blast_radius_exceeded, transitive_trust, concentration |
| Try | Declare reversibility. State can be reverted; responsibility records are append-only. Expand requires that the widened scope is still recoverable. Every operational path has a halt owner (haltability) | expand_beyond_recovery, halt_readiness |
| Pass on | Boundaries stop losses but pass the basis (basis_flow); conclusions are re-checked at the receiving boundary (revalidation). Each decision records its basis from the Upside / Downside / Continuity / Asymmetry viewpoints (decision.basis) | decision_without_basis, review_trigger_missing |
Close: four mechanisms that cut amplification
Extreme downside happens when one failure produces the next, through chaining, reuse, concentration and feedback. VCDesign cuts that amplification with four mechanisms.
| Mechanism | What it cuts | Declaration / mechanism |
|---|---|---|
| Compartmentalize | Spread across compartments | failure_domain, boundary containment |
| Declare a ceiling | The size of the loss | blast_radius (scope and max_loss) |
| Re-check at boundaries | Amplification of upstream errors | Boundary revalidation, upstream_basis_refs |
| Avoid concentration | Simultaneous failure from a common cause | depends_on, the concentration metric |
Extreme events from outside cannot be removed. What can be handled is how far they spread inside.
10. Axioms A1–A5
The axioms are where conformance starts. An implementation that violates any of them is non-conforming however well it satisfies the rest (axioms.yaml).
| Axiom | Statement (summary) |
|---|---|
| A1 Responsibility must not disappear | Every Δ, negative or positive, is assigned to an explicit owner. For a Negative Δ the owner closes it; for a Positive Δ the owner holds what it produced. Responsibility may be transferred or released, but it may not silently become unowned |
| A2 Execution stays within a scope authorized by a human decision | No execution may exceed the scope authorized by a decision closed by a human. Within that scope, loops may act autonomously as often as needed; a change that would exceed it is observed as a Δ and re-decided. Every boundary crossing has a guard verdict; unknown stops and escalates |
| A3 AI does not hold final responsibility | AI may propose, analyze and detect; it may not hold, accept or assign final responsibility. The final decider of every decision is human |
| A4 Temporal separation is inviolable | Fast loops (physical, semantic) must not autonomously rewrite constraints defined by slow loops (value, responsibility) without explicit re-judgment at the appropriate level |
| A5 Responsibility is a scarce resource | An actor's capacity to hold and honor responsibility is finite; overloading a responsible actor degrades every judgment they hold |
When axioms appear to conflict, the order is A2 > A3 > A1 > A4 > A5. Conflicts are resolved by the supervisor or final decider, never by silently overriding either axiom. The conformance checklist is in conformance.md.