Value Continuity Design · v2
VCDesign
VCDesign implements Value Continuity on the side of judgment and responsibility.
Value Continuity is defined as
keeping the ability to create the next value, even as work, people, technology and products change or fail.
Its central principle, the Value Asymmetry Principle, is:
make upside propagable; do not let downside propagate.
Source: the English summary of value-continuity/value-continuity (the canonical definitions)
"Propagable" does not mean "spread automatically". A good result is given a path to spread; whether it actually spreads is decided by a decision (Expand).
What VCDesign specifies
Who decides, on what basis, with which of the six decisions, and who keeps holding what remains.
The definitions and principles of Value Continuity live in the canonical repository and are not redefined by VCDesign. VCDesign implements them as records of judgment and responsibility that can be checked.
Implementation must not begin unless the locus of judgment and the attribution of responsibility are explainable (Implementation Boundary Predefinition).
The core in 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 |
AI governance (AI never holds final responsibility, LLM placement, temporal separation, agent execution gates) is a VCDesign-specific extension kept outside the core.
Check in the order of the five principles
The order of Value Continuity's five principles matters. VCDesign's judgment gate and its metrics follow the same order.
- KeepDecide first what remains when work, owners or technology change
- FindLook for signs of wide spread through reuse, not the average improvement
- CloseDo not predict bad spread; stop it at boundaries
- TryChange within the range you can revert
- Pass onHand the basis, not the conclusion, to the next decision
Unofficial translation of the canonical README §3 (written in Japanese).
After the review, a human closes the decision with one of the six words. See Decisions.
Where to start
-
In manufacturing and OT/IT
Equipment data collection, handovers, a factory AI agent. See how declarations and decisions are recorded at fictional sites.
-
Bringing AI agents into operations
Capability is not authority. Four loops, where LLMs belong, gates before execution, designing the halt.
-
Start from the principle
The definition, the asymmetry principle, the five principles and the six decisions of Value Continuity.
-
Learn the mechanisms
The six core parts on one page, and which VCDesign mechanism implements each principle.
-
Coming from v1
v2 is not compatible with v1. The mapping of vocabulary and records, and where the old pages went.
-
Related projects
VC-AD, TDDD, VMS, Value Review, Re-derivation Layer, Continuity Claim Protocol, idk-lamp.org.
Refer to Specs
This site explains; the norms live in the specifications at github.com/VCDesign-org/vcdesign. When handing VCDesign to generative AI for design assistance, judgment support or code generation, the YAML in the repository is the shortest path.
The authority of VCDesign v2 is these three files (Core, Metrics, Policies):
specs/core/core.yaml— rules for Δ, decisions, declarations, responsibility and boundariesspecs/core/policies.yaml— the judgment gate; rules for responsibility, explanation and halting; the AI extensionspecs/core/metrics.yaml— core metrics ordered by the five principles
Conformance starts from specs/core/axioms.yaml (A1–A5). The overview is the Specification Map; the mapping to the canonical principle is in implementation.md. Much of the specification is written in Japanese.