ECS for Control — Round 2 Outlook

Where the ECS-for-control evaluation goes after round 2: the carried residuals, monitoring and disturbance, recovery on the store, the checker tool, and the path toward lib/v4.0.

Overview

Round 2 built the mechanisms – declared roles, the derived schedule, checked construction, the value store; 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 – the store now copies and compares as one value, and nothing has yet exercised it: capture, compare, restore. It is the recovery motivation's first tangible payoff, and it doubles as the test that the two-state split is drawn correctly – everything the snapshot misses must be re-establishable behind unchanged handles.
the framework step – the candidates sit in the example's lib directory; the questions the step is gated on remain open, where program-specific sizes live first among them.

Monitoring and Disturbance

Round 2 ends with one monitor: the tick reporter, depositing plain deltas when the kernel records a slip – detection and visibility, no judgement. The direction it opens is the monitoring domain proper:

more service spaces – the print facility is one instance of a general shape; progress reporting and disturbance recording are the next candidates: participants deposit what they experience, collectors read across, and the store carries it all as ordinary Components;
discrimination – the step from visible to actionable: transient disturbance decays and is tolerated, sustained disturbance is a signal to act on. Where the thresholds live, and which System owns the judgement, is design work the deposit classes have made cheap to try;
the observation point – a monitor that reads across the store mid-order sees a mid-tick mixture. Whether monitors deserve a defined place in the derived order – a consistent point from which their picture is taken – is an open design question the derivation itself can probably answer.

Recovery on the Store

Recovery selected this architecture, and the architecture now holds what recovery needs first: a state that is coherent at every consistency point, capturable as one value, with everything volatile behind stable handles. The work ahead is to use it:

exercise the snapshot (above) and put the captured state to use – compare across ticks, detect divergence, restore;
give recovery its cases: the direction, already visible in the concepts document's world-creation contracts, is recovery as bounded re-entry – re-running creation's contracts over existing structure, down to a peripheral reset re-entering the build contract for one device, with the handle as the stable name across it;
disturb on purpose: a deliberate disturbance source, so that monitoring, discrimination, and recovery can be exercised against known, repeatable faults rather than waited-for ones.

The architecture stands on its own results – coherent visible state, declared dependencies, a derived schedule, checked construction – and recovery remains the horizon it works toward, on the store it now has.

The Checker Tool

The round's review surfaces are mechanical correspondences – the import matrix, parameter modes against the manifest, identity references against slot writes, loop bounds against the arrays they index (the lessons document collects them). A build-time checker can walk the same surfaces exhaustively: a lexical tool over the program text, no reflection, no run-time presence – the third defence level, tool-assisted as it was always meant to be. The rule ledger is accumulating; the tool is committed, its form open.

Partitioning and Second Schedules

Unchanged from the first round's horizon, and deliberately untouched by round 2: one store under one schedule was the right frame for building the mechanisms. The concepts document carries the partitioned form – interface stores, delayed crossings, per-partition consistency – and round 2 quietly kept the ground clear: nothing in the mechanisms binds them to one core, and the one-schedule deployment is a fact of the current program, not of the concepts.

Toward lib/v4.0

The evaluation converges on two things at once: the framework's next major version, and the official documents that describe it. The rounds are to the documents what the program versions are to the code – editions on the way to the release. The example's lib directory is the visible seam today; its graduation into lib/v4.0 – API and conceptual changes, the handle-based device access first among them – is the evaluation's destination, with form, scope, and impact on existing programs still evaluation work. Programs written against v3.2 remain unaffected throughout.