Oberon RTK

ECS for Control: Round 2 Retrospective

The round-2 outlook tracked against what round 3 delivered: item by item, including the sketched mechanism the round refuted – with the round's lessons folded in.

Overview

The round-2 outlook took over two residuals, opened three directions – monitoring, recovery, the checker – and restated two horizons: partitioning with second schedules, and lib/v4.0. Round 3 – the EcsControlWatch program, the new editions of the concepts and implementation documents, and the four-document Observations set – delivered the monitoring direction far beyond its sketch, delivered partitioning while refuting one of its sketched mechanisms, and moved every carried item. This document goes through the outlook in its own order; what it hands forward is collected at the end, for the round-3 outlook to take over.

The outlook's items, at a glance:

Opened by round 2 Verdict
monitoring and discrimination delivered beyond – the Observations apparatus, calibrated, verified on target
the observation point delivered – the derivation answers it
disturb on purpose delivered – the authored test harness
partitioning delivered – a shared store as meeting place refuted: crossings are transports, hosted not co-owned
the snapshot demonstration carried forward – transformed: recovery is now specifiable
recovery's cases carried forward – recovery and migration delineated
the checker tool carried forward – its scope reduced by construction
second schedules carried forward – the ground kept clear, one position taken
the framework step carried forward, advanced – its gating questions answered

And one axis arrived that the outlook never asked for: the definition disciplines, accounted for below.

Monitoring and Discrimination

Delivered beyond. The outlook asked where the thresholds live and which System owns the judgement, and called it "design work the deposit classes have made cheap to try". What the round built is not a placement of thresholds but an apparatus: events tallied at the source, inside the operation that experiences them; a distiller that weighs the tally into a trouble level; a supervisor that reads the level and commands. Discrimination landed exactly as the outlook aimed it – transient trouble decays and is tolerated, sustained trouble accumulates and trips – and brought with it something the sketch did not anticipate: a calibration discipline. The thresholds are not tuned; they are derived, at world creation, from a declared specification – an accepted rate, a triggering rate, a burst – so that the program's tolerance is an authored fact with a defined detection curve, not a constant that happened to work.

The work settled its own name on the way: observations, not "disturbance recording" – the mechanism counts and weighs but never classifies, so its name stays neutral; the outlook's own noun survives only where trouble is actually being read. The whole apparatus is owned by the four documents of the Observations set, from concepts through calibration and implementation to verification on target.

Of the outlook's two candidate service spaces, one was taken up and one was not: disturbance recording became the round's centre; progress reporting was not pursued. The round went deep rather than wide – one facility, the print buffer, carried the whole evaluation.

The Observation Point

Delivered – and, as the outlook suspected, "the derivation itself can probably answer" was the answer. The distiller and the supervisor are ordinary Systems with ordinary manifests; the derived order places the distiller after the depositors it collects from and the supervisor after the distiller, so each reads a settled picture with no special machinery. The one deliberate cut in the adaptation cycle – the commanded System reading its command – is a declared previous-value consumption, an explicit manifest class with unit-delay semantics, not an accident of ordering. Monitors did not need a defined place; they needed declared edges, which they already had.

Disturbing on Purpose

Delivered. The outlook asked for "known, repeatable faults rather than waited-for ones", and the round built the authored form of that: load cases as locked tables – character and operation counts per beat, named – played by the heartbeat System, sequenced into test runs. The rig is fixed and one thing moves at a time; every run's outcome was predicted before it ran, and the record was compared character by character. The suite's tests confirmed the calibration document's claims on target – detection slopes, invariances, recovery behaviour, the supervisor policies – and the harness ships with the program, re-runnable. The verification document is this delivery.

Recovery on the Store

Carried forward, transformed. The snapshot demonstration – capture, compare, restore – is now twice carried, and the round changed what is being carried. Recovery stopped being an aspiration over the store as a whole and became specifiable: every recoverable unit has a token naming it, with a type, an owner, and a place; a recovery subset is therefore an authored set over tokens, exactly the idiom the deposit surfaces already use; and each token can carry its temporal-depth attribution – re-acquired from the world, reloaded from a capture, or rebuilt as baseline. The round also drew the line the work needs: recovery re-establishes this world; migration builds a different one from inherited state – two problems the store had been letting blur together. What remains is no longer design; it is the doing, and it hands forward with the sharpest specification it has had.

The round's contribution to recovery's trigger side is the observation loop itself: detection with defined sensitivity is now a mechanism, not a hope.

The Checker Tool

Carried forward, its scope reduced by construction. The rule ledger the tool was to walk shrank from both ends while the tool stood still. Rules migrated down into the language – named signature types, the closure of the locked modules, read-only exports – where the compiler holds them finally; and rules migrated into the gate – the tokens, the manifests, the construction checks – where the program refuses itself. The implementation document closes with the map: invariant by invariant, the tiers that hold it and the constructs that carry it. The checker's territory – the review legs – is readable off that one table; the walks themselves stand in the chapters. The commitment stands; the tool is smaller than it was going to be.

Partitioning and Second Schedules

Partitioning: delivered – with the round's one refutation inside it. The program is four partitions, each owning its complete family of definition and store modules and its own creation procedure; the main program module is reduced to calling the partitions in order. The outlook's inherited sketch – "interface stores, delayed crossings, per-partition consistency" – had itself forked the meeting place: a plain hand-off met in a small store both sides are wired to, while an interaction with computation of its own earned a sub-system whose domain is the coordination. The two branches fared differently:

  • the co-owned store is refuted, on principle: shared state across a boundary makes the two sides co-owners of one picture, which is the definition of being one partition – and a store both sides are wired to has no host: no single creation phase builds and values it, no one partition's declarations cover it. The interface function is delivered instead as transports – a sampling port, a deposit surface – each hosted in one partition's store under one authority, the peer participating through the transport's protocol and reaching nothing else;

  • the transformation branch is confirmed and strengthened: the coordination partition is its instance – and the crossing itself may carry no computation at all: an adapter is a route, never a party; a transport carries strictly values. Where an interface needs transformation, the transformer is a System in a partition, with transports on both sides.

Delayed crossings and per-partition consistency stand, carried by the transports. And partitioning itself settled as a capability, not a doctrine: the partition boundary follows the program's mechanisms – never cutting through one – and a program small enough to be one partition legitimately is one.

Second schedules: carried forward, deliberately unbuilt for the third round running – and the ground is not merely kept clear but surveyed: a schedule cut shows up in the architecture as nothing but a transport, and the concepts document now discloses the foreseen extension at the asynchronous seam. One schedule on one core remains a fact of the current program, not of the concepts.

Toward lib/v4.0

Carried forward, advanced. The questions the outlook said the framework step was gated on are answered. Where program-specific sizes live: in the program, always – every cardinality is a world fact, authored in the program's definition modules, and a library module that would hold one fails the fact-authority rule mechanically. What shape the service modules take: mechanics or algorithms – instances and cardinalities are the program's, the machinery and the mathematics are the library's. Which modules are candidates: they self-identify, and the round added to them – the observation machinery, the port disciplines, the generic ring buffer index. The delineation of v4.0 – the API-freeze list, the fate of the kernel, the impact on existing programs – is the committed next step; programs written against v3.2 remain unaffected, as they have been throughout.

Beside the Outlook: The Definition Disciplines

The round's largest unplanned delivery answered a question the outlook never asked. Partitioning's rework surfaced a defect that every construction check passed over: a single declared token claimed jointly across arrays that the partition boundary had split – the declarations were internally consistent and collectively wrong. No check could see it, because the correspondence between the store's variables and the discipline's declarations was itself undeclared.

The repair became a family of disciplines: one token per store variable, manifests written verbatim from the declarations they claim; named array types at the system seam, so signatures are checkable statements; every fact authored – no value in the program is "the next free number"; values authored in one place and locked in another by language means alone. Around them the round built the frame that says, for every rule, where it is held – by the language, at the gate, or by review. None of this was foreseen; all of it is now the spine of the implementation document.

Lessons

The method that produced the round, kept for the rounds after it:

  • Predict, then run. Every verification run's outcome was computed before the run, and the comparison criterion was character-exact. The traces stopped being output to interpret and became evidence to check; the suite's one deviation from prediction was itself a finding – understood, and in the tested policy's favour. Plausible-looking output confirms nothing.

  • Writing the documents is a verification pass. The implementation document's claims were checked against the sources both ways – every invariant to the constructs that carry it, every construct to the invariants it serves – and the pass found real defects: stale headers, a claim the code had outgrown, an inversion that did not hold. The write-up is not a report on finished work; it is the last review the work gets.

  • Discipline comes from friction. The definition disciplines were not designed; they were extracted from a defect the checks could not see, then hardened into structure and moved down the enforcement tiers. This is also why the round's lessons are a section and not a document: the useful ones were converted into the current documents while the round ran, and doctrine does not need restating as anecdote.

  • Absence carries as much as presence. Much of what holds the invariants is what modules do not contain – no exported procedures on the locked modules, no imports between Systems, no pointer into a peer's store. Absences verify differently from presences – an exhaustive empty search rather than a sampled walk – and the review gets stronger when it knows which of the two it is doing.

  • Retire names that overpromise. "Disturbance recording" became observations because the mechanism never judges; other working names fell for the same reason: a name is a claim about the thing, and claims get reviewed. The vocabulary that survives – observation, transport, gate – is the part of the architecture that costs nothing to enforce.

Carried into the Round-3 Outlook

  • recovery, now specifiable – the authored recovery subset over tokens, per-token temporal depth, recovery delineated from migration; the snapshot demonstration is no longer blocked on design, only on doing;

  • the temporal domain – the round closed at a deliberately drawn line: everything on the operations side of the clock is built and verified; producer rates, deadlines, and whole-program timing requirements lie across it, and they are the natural next country;

  • the framework step – the v4.0 delineation, its gating questions answered, its candidates named;

  • the checker – smaller than planned by construction, its territory readable off the implementation document's closing table.

See Also

Last updated: 1 September 2026