Stock/flow governance — strategic, tactical, action
A self-improving system measures its derivative and forgets its integral: it optimizes adding, never removing. How Nika OS separates stock from flow into three loops running at distinct cadences, and why no mutation is allowed below the drift half-time.
The failure nobody sees coming
A self-improving harness naturally measures flow: did today’s task land, how long did it take, at what cost, with what quality drift. That is the system’s derivative, and it is the right signal for tuning execution.
What it does not measure is the integral: the accumulated stock — the tooled skills, the scripts, the deliverable folders, the rules, the memories. Nobody decided this; it is a mechanical consequence of which instruments were chosen.
And that consequence has a name in control engineering: a one-way actuator with no reset drifts into saturation. If the only available move is “add”, then every improvement loop, however perfectly tuned, converges on an obese system:
- two ways of doing the same thing, each half-maintained;
- skills nothing calls any more, but which the router still sees;
- a tool choice that grows less deterministic as the catalogue grows — until, in the end, a model that draws lots between three near-identical tools.
The intuitive fix — “a more powerful meta-curator, one that looks at everything” — is the wrong one. Mixing stock and flow in a single loop means forcing quantities whose time constants differ by two orders of magnitude to share a control law: cost explodes, robustness drops, and nothing is gained. The right answer is a cascade of loops with separated cadences.
Three loops, three cadences, three quantities
One vocabulary for three readings of the same system. It is control engineering, and it is also, word for word, the structure of an industrial Hoshin Kanri.
| Level | Cadence | Quantity measured | Role | What it looks like in Nika OS |
|---|---|---|---|---|
| Strategic | weekly | stock (integral) | generates the setpoint | inventory of skills, scripts and deliverables → what to merge, deprecate, generalize |
| Tactical | nightly | stock → flow transfer | allocates the authority to act | flow curation, learning dosage, application of validated mutations |
| Action | per turn | flow (derivative) | fast regulation, disturbance rejection | pod execution, tool usage, security/quality gates |
The golden rule cuts across all three: each level acts at the scale where its signal rises out of the noise. Piloting the strategic level at the frequency of the action level is thrash — at low frequency, over-reacting does not improve the loop, it just relocates the instability.
Hence an implementation constraint that looks technical but is doctrinal: the stock loop never writes into execution. It produces a setpoint report that the nightly loop consumes. Stock is a setpoint generator, never direct feedback on the turn in progress. The setpoint goes down, the measurement comes up — both directions flow, but never through the same channel and never at the same cadence.
What stock measures
Four indicators, computed separately for each family of stock (you never compare a skill with a deliverable):
- Redundancy — how much of the stock is a near-duplicate? Measured by semantic similarity within a family, then grouped into components.
- Dead stock — how much of it never got used over the observation window? Units that are too recent are excluded: they have not yet had the chance to be called, and piloting on noise is worse than not piloting at all.
- Routing fragmentation — does a given intent map to one clear skill, or to three ambiguous ones? This is the entropy of the choice. Low, and routing is legible; high, and the system draws lots — which is exactly where tool hallucinations are born.
- Stock/flow ratio — is stock growing faster than it is being used? It is the only one of the four that captures a dynamic rather than just a state, so it is the most important: its monotone growth is the very signature of the saturation described above.
One point of method that matters more than the formulas: two units that are very similar but used successfully in distinct contexts are not duplicates. That is useful diversity, and crushing it in the name of tidiness destroys robustness. A pair’s redundancy score is therefore weighted by the overlap of its usage contexts: we merge what serves the same use, not what merely looks alike.
The drift half-time: why we never act on a single measurement
A stock indicator is a slow signal buried in high measurement noise. One week of usage says almost nothing. Reacting to a one-off measurement means mutating on noise.
Each indicator is therefore filtered — scalar Bayesian state estimation (Kalman/EWMA), plus a cumulative change detector of the Page-Hinkley kind. Both building blocks are public classics, and they were chosen precisely because they stay auditable: you can always say why the system moved.
The filter yields the quantity that governs the whole of governance, the drift half-time: the number of cycles below which an observed change is not distinguishable from noise. That is the time constant below which no mutation is allowed.
And the sequencing never inverts:
change alarm → proposal → gates → application on the next cycle.
An alarm is an instruction trigger, never an immediate reaction.
The framework applies to itself: we move to a richer estimator (multivariate, or with a learned gain) only if the data justifies it — measured correlation between indicators, or residuals of the linear filter that stop being white. And there is one bound we accept on purpose: a fully learned state model, whose decisions we could no longer explain, is excluded by principle. Security first means auditability first.
Three operations, only one of which creates value
For each group of near-duplicates, three possible moves:
- Merge — keep the unit with the best proven usage, redirect the calls.
- Deprecate — mark obsolete and redirect; physical deletion is deferred by one cycle, after non-regression has been observed.
- Generalize — the duplicate was hiding a shared abstraction: we extract the parent primitive.
The third is the only one that is not housekeeping. It is the primitive factory: an observed mechanism that works, whose signal has risen out of the noise, is abstracted into a reusable building block and flows back up to enrich the policy. The drift half-time keeps that induction honest — we do not promote a lucky break into a primitive.
Autonomous mutation, immutable security
This is the point of doctrine that surprises people most, and it is the heart of the design.
Mutable autonomously, with no human validation, on measured proof: methods, scopes, workflows, skills, implementation strategies. The canonical example: if one information-retrieval strategy measurably beats another over a given scope, the system switches strategy on that scope, on its own. That is what makes it antifragile rather than merely robust.
Immutable, never mutated — not automatically, not otherwise: the constitutional layer. Security, secrets, data egress boundaries, critical processes, identification invariants, network isolation. The kernel does not mutate itself.
The distinction that makes the two compatible is about the nature of what is being touched:
We mutate the method, never the security principle.
The principle “no factual claim without verification” is immutable. The implementation of that verification is mutable on proof, as long as the principle holds. Confusing the two means either freezing solid or scuttling yourself.
A design consequence, not a detail: a mutation that would touch the immutable layer is not escalated to a human for arbitration — it is refused and logged. A boundary that can be negotiated case by case is not a boundary.
What replaces human validation: five conjunctive gates
The guardrail is no longer “someone validates”, it is “the measurement validates”. The five conditions are conjunctive — all of them must pass:
| Gate | What it requires | What it prevents |
|---|---|---|
| Immutability | the mutation touches no constitutional path | kernel self-modification |
| Observability | enough observations, units old enough | piloting noise |
| Drift out of noise | change detected and a gap of several standard deviations | reacting to a fluctuation |
| Bandwidth | never two mutations on the same unit within one drift half-time | thrash |
| Reversibility | unit versioned, rollback point identified, dry run passed | the irreversible |
Two dosing principles complete the gates. First, the step is never all-in: on a noisy signal we apply only a bounded fraction of the candidate mutations per pass, sorted by expected effect — and we keep probing. Second, the first pass applies nothing: it produces its report and its proposals. Applying is an explicit, later act, once reversibility has been demonstrated on the real stock.
Closing the loop: rewarding parsimony
One last lever, without which everything else is rowing against the current. If the learning signal only rewards flow — “the task is done” — then rewriting a building block that already exists pays as well as reusing it. The system learns to add.
The learning signal therefore also carries a parsimony term, weighted and bounded:
- reusing an existing block, or generalizing into a parent primitive: rewarded;
- creating an artifact that has no equivalent: neutral — creating is not a defect;
- recreating what already exists to functional identity: penalized.
And one rule of measurement honesty, valid across this whole page: an indicator we cannot measure on a given cycle is reported as “not measured”, never as zero. A default zero is a false green, and a false green costs more than a declared hole — because it makes you stop looking.
In one sentence
Measuring flow tunes execution; measuring stock is what keeps a self-improving system from growing until it chokes — provided each loop acts at its own cadence, nothing mutates before the signal rises out of the noise, and the security layer, for its part, never mutates at all.