This page contains historical documentation from the BOA/RCA/RP era. It is not the current authoritative specification of VCDesign. Please refer to the current Core specifications (core/core.yaml, core/policies.yaml, core/metrics.yaml) for authoritative guidance.
This concept has been superseded by the Core + Policies + Metrics model. Refer to specs/core/ for current definitions.
This document represents the conceptual lineage that led to the current model.
PHILOSOPHY
— Reason for VCDesign's Existence —
Prelude — The Premise of Time
There are two timeframes in the lifecycle of software:
"Production Time" and "Usage Time".
Until now, the core of engineering has been focused on
how efficiently "Production Time" can be shortened.
To increase production efficiency,
various methodologies and architectures have been trialed.
And now, "production" itself is being automated by AI.
In AI-driven production,
structures need not be understandable by humans.
Mathematically optimal solutions are simply generated.
Even if production is automated, the human role does not disappear.
What to make, how far to take it, when to stop.
Judgment, coordination, and the placement of responsibility remain.
Furthermore, systems continue to be used after they are made.
"Usage Time" is overwhelmingly longer than "Production Time".
When automated production becomes the premise,
the cost of "Production Time" drops,
allowing us to face the true reason for the system's existence.
That is the question of
how to maintain "Usage Time" for as long as possible.
Keep the system or discard it?
The criterion for judgment is simple.
Does it still demonstrate value?
The lifespan of a system is not
its uptime or years of maintenance,
but the time during which it continues to demonstrate value.
Value Continuity Design (VCDesign) is
a design to incorporate the prolongation of the state of demonstrating value
into the design from the very beginning.
VCDesign (Value Continuity Design) is not
a philosophy dealing with how to "create" value.
What VCDesign deals with is
the condition for the time during which value continues to be demonstrated not to be severed
midway.
This is not a philosophy born from ideals.
It was born from observations that could not be avoided.
About this Document
This document records
"why VCDesign had to exist."
- It does not explain how to use it
- It does not justify implementation
- It does not try to persuade the reader
What is written here is only
the preconditions and their consequences
observed repeatedly in the field of design and operation.
Observed Severance
In systems where operation continues,
regardless of domain or technology, the same phenomenon appeared repeatedly.
Judgments are made.
However, as time passes, no one can answer anymore.
- Why was that judgment made?
- Under what premises was it valid?
- Who was taking responsibility for it?
This was not caused by a lack of effort or ability.
It was caused by the fact that
judgment itself was not treated
as a design object to be inherited across time.
Judgment dissolves into
meetings, chats, and tacit understandings,
and eventually becomes no one's.
The system keeps moving.
However, value was quietly lost.
The Premise of Constant Updates
With the progress of automation and generative technology,
systems can no longer escape the following premises:
- Implementations continue to be updated
- The marginal cost of improvement drops indefinitely
- Trial and error is immediately reflected in reality
Completion is not the end point,
but became the starting point of operation.
In this environment,
"Is it okay to update?" rather than "Can we build it?"
becomes the center of judgment.
Optimization does not stop.
If not stopped, it keeps advancing.
The Fact that Boundaries are Not Designed
In an environment where updates are the premise,
systems where boundaries are not designed
inevitably fall into the same state.
- No one has the responsibility to stop
- Short-term rationality erodes long-term trust
- The basis of correctness is absorbed by results and numbers
What is broken at this time is
neither code nor function.
It is the condition under which judgment is allowed to be valid.
VCDesign's Stance
VCDesign:
- Does not define correct judgment
- Does not automate responsibility
- Does not give directions for optimization
Instead,
it designs the place where judgment is allowed to validly stand as final.
It does nothing more.
It does nothing less.
Shift of Design Object
What VCDesign takes as its design object is:
- Not functions
- Not flows
- Not optimization algorithms
It is where judgment and responsibility are taken.
Judgment appears in places
that cannot be easily corrected later.
That is why
judgment must be treated not as a "result"
but as a design that spans across time.
Reason for Being Machine-Readable
Humans are
excellent at consensus building and discussion.
However,
they are poor at maintaining boundaries across time.
VCDesign Core is expressed in machine-readable form
not for implementation.
- To fix judgment conditions
- To prevent boundaries from deteriorating
- So that humans and systems refer to the same premises
This is a design choice.
Relationship with AI
AI can generate interpretations.
However, it cannot take responsibility for results.
VCDesign does not
try to make AI safe by controlling it.
It makes it safe by not letting AI decide where responsibility begins.
AI is not an agent of judgment.
It is an existence that illuminates the premises under which judgment stands.
Finally
If this philosophy looks strict,
it is because it was born from a place where looseness could not survive.
VCDesign is not
a philosophy to stop change.
It is a philosophy to protect the conditions under which value is not severed
amidst change.
Positioning
- Upper: VCDesign Constitution
- This Document: Reason for Existence (Why)
- Lower: Manifesto / Narrative / Tools
This document records
why VCDesign was placed here.