ECS for Control: Round 3 Outlook

Where the ECS-for-control evaluation goes after round 3: several schedules and cores, the temporal domain, detection and decision, recovery made specifiable, the declared world completed, the asynchronous seam, and the staggered path to lib/v4.0.

Overview

Round 3 built partitioning and observations – the four-partition program, the transports between its stores, and the calibrated observation-and-adaptation loop, verified on target; the retrospective accounts for that delivery against the previous outlook, and this document is forward-only: what stands open, and what the round's results make reachable. The next round's programs will carry a new name; nothing here presumes their shape.

Carried Forward

Two items come over from the retrospective's closing list, tracked here so they cannot quietly disappear:

the snapshot demonstration – capture, compare, restore – now carried with a specification rather than an aspiration behind it: Recovery on the Store, below, has the details;
the checker tool – smaller than it was going to be: the rules it was to walk have partly migrated into the language and the construction gate, and its remaining territory – the review-held legs of the invariants – is readable off the implementation document's closing table. One question has joined the commitment: reviews are not all of one kind – some check the program against the world's facts, some against the architecture's rules, some against authored agreements between parties – and only some of these are a tool's to take over. Sorting that out is part of scoping the tool.

Several Schedules, Several Cores

The horizon standing since the first round, and the most consequential item on this list. Three rounds have deliberately run one schedule on one core – and built, piece by piece, everything the step needs: partitions with private stores, crossings with transfer semantics, and the rule that a schedule cut demands nothing beyond transports already in place. The claim is on record in the concepts document: where a partition runs – same schedule, second schedule, second core – is a deployment decision, not an architectural one. Proving it is due: the same program, cut along a declared boundary, its parts paced independently and meeting only at their transports.

This step and the temporal domain, below, are two halves of one arc: under one schedule, rates are a design convenience; with several, the rate relation at every transport is a deployment fact the crossing must carry. And the asynchronous seam, further below, is this step's limiting case – a peer paced by hardware rather than by a second tick.

The Temporal Domain

The round ended on a deliberately drawn line. Everything the observation work builds and verifies is denominated in operations and events; time enters only at authored boundaries, converted once. That line was the right one to close a round on – and it is the frontier the next rounds face:

producer rates as declared facts – what turns an operation count into a duration is a rate, and rates are exactly the kind of fact the discipline wants authored, not assumed;
deadlines and budgets – from "the drain keeps up on average" to stated requirements: how late may a value be, how much of a tick may a System spend, what happens when the answer is "too much". The kernel's timing instrumentation is the seed of the measurement side;
the whole-program view – periods, phases, and rates chosen together against the controlled system's demands: the entry of control-theoretic requirements, where the evaluation's vocabulary meets the plant's.

The kernel is this domain's principal object – tick, periods, scheduling – which is why the framework step below stays behind it: the kernel's surface should survive the temporal round before any release freezes it.

Detection and Decision

Before recovery comes the question of when to invoke it. The round built one detection family to full depth – the observations: gradual trouble, calibrated thresholds, an escalation ladder with authored rungs. The other family is the run-time error: assertion failures, the language's own checks, hardware faults – already unified on one path in the framework. What does not yet exist above the two is a program-wide run-time error concept: the map of where failures can occur, which family detects each, and what follows. Among what it has to answer:

where an assertion is even useful – creation's assertions are settled, refusal at the gate is their job; and the steady-state winnowing has begun: a NIL test over memory that is never zeroed at load tests garbage against a constant – theatre, not detection. The criterion behind that winnowing wants stating in general form;
where an assertion is allowed – may a System assert? A failed assertion mid-tick ends the pass, which collides with run-to-completion; the alternative reading is that a System's preconditions are the gate's guarantees, and their violation in steady state is supervision's business, not the law's;
the decision layer – a trap and a tripped level are detections of different species; which findings escalate to a restart, which invoke recovery, which degrade and continue, is policy that belongs to the program, stated program-wide, not improvised per site.

This concept and the recovery mechanics below are deliberately orthogonal, in concept and in implementation: detection-and-decision says when and whether; the store's recovery machinery is one of its remedies – complete without it for a program whose only remedy is a restart, exercisable without it from a test, invokable from either detection family.

Recovery on the Store

Recovery remains the horizon, and the round moved it from aspiration to specification. What now stands: every recoverable unit has a token naming it, with a type, an owner, and a place; a recovery subset is an authored set over tokens; each unit carries its temporal-depth attribution – re-acquired from the world, reloaded from a capture, or rebuilt as baseline; and recovery is delineated from migration – re-establishing this world versus building a different one from inherited state – with world identity deciding which is happening. What invokes it is Detection and Decision's business, above.

The work ahead is the doing, and the round's own methods carry over to it:

exercise the snapshot – capture, compare, restore, against the specification above; the specification's carrier may well be structure rather than annotation – the store dividing along the restore classes, with capture as one record assignment – and the token layer is invariant under any such regrouping, so the declared world does not move;
verify recovery the way the observations were verified – the test harness can disturb on purpose, and the predict-first, character-exact method applies to a recovery cycle as it did to an adaptation cycle;
give creation its remaining phase – a self-test at the gate is a natural fifth phase of world creation, and recovery's re-entry would pass through it like any other start.

Observations, Continued

The apparatus is built; the round used it on one facility. What it opens:

severity – the tally counts events; a weighted form would let one grave event outweigh many trivial ones, a calibration extension rather than a redesign;
more instruments – the tick monitor still prints directly and names its own future: an observation-based form, feeding the same distillation it currently bypasses; the heartbeat regains its reporting purpose now that its test-driver duty is done;
more facilities – the tally-distil-supervise shape was built facility-agnostic; queues, ports, and drivers are candidates as the programs grow.

Completing the Declared World

One asymmetry is stated openly in the implementation document: access to the variable store part is declared, checked, and walked; access to the locked part is held by review alone. A declaration class for locked-value consultations would bring those reads into the same picture – attributable, surveyable, their cross-partition cases visible in a manifest rather than a search. The construction checks would gain nothing – locked values are schedule-inert by definition – so the case rests entirely on review and change-impact value, and possibly on a split by locality: consultations of one's own partition's locked values against consultations of a peer's published interface, the latter checkable for containment. Whether that pays its way is evaluation work, committed but undecided.

The Asynchronous Seam

The concepts document carries a footnote where this direction waits: the transport protocols serve an unsynchronized peer by design, and an interrupt-driven unit is exactly such a peer – paced by hardware rather than by a tick. Treated as a System of its own schedule, with its port hosted in a store and its production declared, the asynchronous seam would fold into the partition crossing, and one rule – asynchronous units are not Systems – would dissolve into the general case. The machinery to evaluate is the external-producer declaration; the partitions and transports are already the right shape – this seam is Several Schedules, Several Cores in its hardware-paced limiting case.

Toward lib/v4.0

The framework step advances from direction to plan. The next round delineates: the graduation criterion is already mechanical – a module holding any program fact fails it – and the delineation names the candidate roster with each module's stability, the launch set, and the documentation conventions for two coexisting lines. What the delineation does not do is release.

The release, when it comes, is staggered, each stage its own release with its own change note:

lib/v4.0 for the RP2350, with the ECS evaluation programs as its examples – largely publishing what the evaluation built;
the curated example programs for the RP2350, ported and target-verified;
the same two steps per further MCU family – the handle-based architecture is API-level, but every driver body is chip-specific, so each family is its own body of work.

The gate stands at the head of the ladder, and pulling it is a judgement, informed by the temporal round's effect on the kernel surface, by demand, and by the bench budget the ladder needs – not a date. Throughout, the versioned trees do what they were made for: the v3.2 examples remain shipped and correct against their own library, indefinitely, and programs written against v3.2 remain unaffected.