Lab · Evolution harness
The passive surface for operator-directed change
Anvil is a harness for shaping systems through bounded transformations. It does not decide what to build, verify behavior, or optimize plans. It provides the surface, the cycle, and the append-only record from which CDE projections and BCS evidence can make system evolution legible.
- Fixed harness: only State, Transformation, and Event live inside Anvil; planning concepts are reconstructed as projections.
- Operator-directed: drivers, capabilities, constraints, insufficiency resolutions, and reconciliation remain human-authored decisions.
- Evidence-agnostic: BCS is the universal evidence channel, so tests, probes, telemetry, and fitness functions all arrive as constraint verdicts.
- Event-sourced backbone: the append-only log is canonical; CDE views are rebuildable pure functions over Event[].
3
Internal primitives
State, Transformation, Event. Everything else is a projection or an external concept.
5
Cycle phases
Authoring, planning, execution, reconciliation, and deferred late verdicts.
pass/fail/pending
Verdict vocabulary
Pending is first-class so temporal constraints can mature after iteration completion.
Architecture
A fixed harness between intent and runtime evidence
Anvil owns execution mechanics, not meaning. CDE gives the operator readable projections from the event log; BCS supplies constraint verdicts from the runtime. Keeping those responsibilities separate is the core move.
Operator
Defines, approves, resolves, reconciles
Human direction enters as explicit operations, never as hidden automation.
Anvil
Executes transformations, records events, and orchestrates evidence pulls.
Harness
CDE
Computes legible planning and reconciliation views from the event log.
Computed projection
BCS
Specifies and evaluates behavioral constraints on the runtime system.
Operator authors, runtime evaluates
Runtime
The system under evolution lives outside the harness. BCS observes it, Anvil applies transformations to it, and the operator reads the resulting projections.
Responsibility boundary
The operator authors drivers, capabilities, constraints, and reconciliation narrative.
Anvil executes transformations and records enough history to reconstruct every view.
BCS evaluates behavior. Anvil only pulls pass, fail, or pending verdicts.
Internal ontology
Only three things live inside Anvil
Driver, capability, iteration, outcome, and lineage are intentionally not stored as primitives. They are reconstructed from events so legibility does not contaminate execution.
State
The harness working memory: current capability-state vector, in-flight transformation context, and pending pulls.
Current state is useful during execution, but the event log remains the durable source of truth.
Transformation
A bounded change applied during execution, parameterized by capabilityId and targetOrdinal.
It produces a new state and emits an event; it is not a planning object.
Event
The atomic record: timestamp, transformation reference, pre/post delta, operator interactions, and BCS results.
The log is append-only. Driver, capability, iteration, outcome, and lineage are reconstructed from events.
CDE layer
Planning objects are views over the log
| Projection | Computed from |
|---|---|
| Driver | DriverDefined events and many-to-many constraint bindings. |
| Capability | CapabilityDefined and CapabilityRevised events: ordinal ladder, effort, and per-ordinal constraints. |
| Iteration | Bounded event sequence between start and completion or cancellation. |
| Conformance(c, n) | Verdict aggregate over constraints bound to a capability and ordinal. |
| Outcome | Achieved ordinals, divergence classes, pending constraints, actuals, and operator narrative. |
| Lineage | derivedFrom chains across capability revisions with referenced decisions. |
Operator interface
Six operations make the human boundary explicit
defineDriver(d)
asyncEmits DriverDefined; optionally binds to constraints.
defineCapability(c, ladder, effort, bindings)
asyncEmits CapabilityDefined with ordinal-granular constraint bindings.
defineConstraint(beta)
asyncEmits ConstraintDefined for later driver and capability binding.
approveIterationPlan(plan)
syncRequired to move proposed work into planned execution.
resolveInsufficiency(signal)
syncBlocks execution until the operator extends, redefines, descopes, or cancels.
reconcile(iteration, achieved, narrative)
syncCloses the outcome while preserving pending evidence.
Complete cycle
Iterations close, evidence can still mature
Authoring
Operator · async
DriverDefined, ConstraintDefined, CapabilityDefined
Planning
Operator · sync approval
IterationStarted
Execution
Anvil · sync per target
TransformationApplied, ConstraintResultPulled, InsufficiencySignaled, InsufficiencyResolved
Reconciliation
Operator · sync
IterationCompleted
Deferred
Runtime · async
LateVerdict
Reconciliation is monotonic, not final
- Read achieved ordinals from the final state vector.
- Pull conformance per achieved capability ordinal.
- Classify divergence for each target mismatch.
- Record state-definition fit, pending constraints, effort actuals, timeline actuals, and operator narrative.
- Recompute historical outcomes when late verdicts arrive instead of mutating prior completion events.
Insufficiency protocol
Anvil blocks when the workpiece does not take shape
A transformation is insufficient when the expected state delta does not materialize or BCS conformance for the target ordinal fails. Pending verdicts never trigger insufficiency; only fail does.
extend
Define a new capability, bind it to the active iteration, and resume.
redefine
Revise the capability ladder or constraint bindings, then resume.
descope
Drop the failing target from the iteration and continue on remaining work.
cancel
Terminate the iteration and reconcile what was achieved.
Boundary commitments
What Anvil refuses to be
Not self-evolving
The harness primitives are fixed; Anvil does not modify itself.
Not autonomous
Every driver, capability, and constraint originates from the operator.
Not a verifier
Anvil pulls BCS verdicts; it does not evaluate constraints.
Not a planner
Plans are operator-approved; Anvil orchestrates execution.
No hidden continuity
Durability lives in the append-only event log, not opaque state between iterations.
Domain-agnostic
The runtime can be services, sites, code, schemas, or infrastructure artifacts.
Locked decisions
Architecture as rejected alternatives
| Decision | Selected | Rejected | Rationale |
|---|---|---|---|
| Direction | External, operator-driven | Self-directed | Avoids bootstrap recursion and keeps responsibility explicit. |
| Internal ontology | Minimal {State, Transformation, Event} | Full CDE internally | Keeps harness primitives uncontaminated by legibility concerns. |
| CDE relation | Projection over events | First-class internal types | The event log stays the single source of truth. |
| BCS relation | External runtime evaluator | Internal evaluator | Anvil consumes evidence; runtime-side BCS produces it. |
| Reconciliation closure | Monotonic with late binding | Closed at iteration completion | Honors pending verdicts and temporal evidence horizons. |
Naming
The metaphor precommits to the architecture
- The anvil is passive: it does not strike; it provides the surface for directed force.
- Strikes are bounded and repeated: each iteration shapes the workpiece under explicit constraints.
- The smith is the operator: the human holds the tools, judges insufficiency, and decides when to stop.
- The workpiece is the runtime system: shaped through transformations, then tested elsewhere through BCS.
Caveats
Anvil is a harness specification, not an autonomous product promise. Its value depends on disciplined operator decisions, a durable event log, trustworthy BCS evaluators, and projections that can be rebuilt from events without hidden state.
Want to shape system evolution with explicit constraints and an auditable event trail?
Initiatives &
Research
Beyond my personal consultancy, I am actively building the future of software delivery and collaboration through these dedicated entities.
api.land
Curated infrastructure and building blocks for modern engineering teams. Providing the modules you need to build faster.
intelligence.space
A research lab re-imagining human-AI collaboration. Building an "Intelligent Space" for the entire lifecycle of systems engineering and learning itself.