Tamoz, technically: from sensor event to governed action to learned rule

What has been shown, and how

Reviewed on 3 November 2026 against the revisions in section 22. Read a result at its own level, and don't add the levels together.

Start from your question.

• Can the model act beyond its authority? Sections 4, 5, 6, then 9.
• Can it learn without grading itself? Sections 10 and 12.
• What did the pump trial prove? Sections 18 and 19.
• What happens on real hardware? Section 20.
• What would stop you using it? Section 21.

Watch the walkthrough

A step-by-step walkthrough video of how an agent handles a live sensor stream. The written version of that path is sections 1 to 6.

1. The system at a glance

The problem this layout solves is putting judgment close to equipment without putting authority there. Three components, each with its own job and its own repository. They talk only through typed, digest-bound contracts: JSONL traces or plant wire for events, gRPC episodes over a Unix socket, server-sent events for outcomes, and plant wire for device commands. The shared canonical form comes with test vectors that both the Ruby side and the Go side must reproduce byte for byte, so a digest means the same thing on both sides.

The system has three parts, and on this site the whole is called Tamoz. Agentic Stream (Go) is the streaming runtime. Tamoz (Ruby) is the agent framework that reasons inside each episode; it works with any model, and the pump-station trial used GLM through z.ai. Streams Simulator (Go and a React canvas) began as a test world with a sealed answer key and now also acts as a plant wire node (section 16). The newest piece is the playbook: a set of deterministic rules, each learned from verified repairs and approved by a person, that answer a recurring kind of case without a model call (section 12).

The split of responsibilities is written down as a contract, and every design question gets settled by asking which side of it a concern falls on:

Twelve joint invariants are release-blocking for the pair. They come from a private integration document that requires an executable test for each, and this page doesn't claim all twelve have one. A few of them carry most of the design. Both sides compute byte-identical snapshot digests. Tamoz never computes event time, a watermark, lateness, or window membership. The stream never calls a model on its deterministic path. Every attempt is identified by (episode_id, attempt_id, fence), and output from a stale attempt is refused even if its snapshot matches. And no intent executes without passing the stream's policy pipeline, whichever executor produced it.

2. The stream plane: from events to Situations

Agentic Stream is a modular monolith in Go 1.26: one process, SQLite in WAL mode, restricted CEL for rules, and YAML SituationSpecs compiled and digested at load. Here's the path of one event:

1. Validateenvelope + schema
2. Appenddedup by stable id
3. Partitiontenant + key
4. Watermark+ source health
5. Windowstumbling, sliding
6. Operatorsaggregates, slopes, heartbeats
7. Situation vNimmutable, digested

A Situation version carries the derived facts, the lifecycle phase, severity, completeness, the material delta since the last version, a provenance summary, source references, and a canonical digest. A later event never rewrites a published version. It produces a new correction version. Lateness isn't a silent default either. Each spec declares its bounded out-of-orderness, idle timeout, allowed lateness, clock-skew tolerance, and one of four policies:

A missing heartbeat is a first-class feature. When a source goes quiet, completeness becomes uncertain, and every downstream gate can see it. That's how "the probe went silent" turns into a denied emergency action instead of a confident guess.

Where this can fail. A correction is only as good as the reducer behind it. Round 5 found one that picks its winner by event time, so a corrected running total never replaced the stale one (F-1 in section 21).

3. The cognitive scheduler: when reasoning is worth paying for

Admission is a deterministic decision the stream makes. The agent never decides whether to wake up. Every outcome (ignored, deferred, coalesced, admitted, cancelled, expired) is recorded with a reason, so cognitive cost is always explainable after the fact.

Supersession does most of the work here. If a newer version materially changes the Situation while an episode is still thinking, the attempt is cancelled, and its fence guarantees a late answer can't be accepted. If a correction arrives after a command already executed, the stream admits one deduplicated reconsideration bound to the corrected version.

Numbers from the early simulator rounds. Only the first measures the scheduler's selectivity:

One caveat that matters for the playbook: the scheduler's debounce and cooldown count wall-clock time today (see section 19).

4. The episode boundary

This is where continuous evidence turns into one bounded, supervised piece of reasoning. Tamoz implements the EpisodeWorker gRPC service with three RPCs. Handshake and Execute run episodes. DraftPlaybookRule is optional and separate: the worker announces it in the handshake only when started with a drafting model, and it only drafts rules (section 12.2). The stream dials it over a Unix socket (mTLS optional). The worker is authoritative for nothing. It proposes, and the runtime decides.

Tamoz isn't the only executor. Agentic Stream also ships a fixture executor and an in-process native one, which it uses when no --worker-socket is given, running a deterministic provider unless a model endpoint is configured. Rule decisions have their own executor (section 12.6). All of them return to the same validation and policy path, so the boundary below is about what any executor may do. The results on this page used the Tamoz worker, except where a round says it used a scripted one.

A few details make this boundary hard to abuse:

• The snapshot is sealed. The request carries snapshot_json and its SHA-256, plus digests of the decision schema, tool catalog, prompt, and objective. A strict scanner refuses malformed JSON at the door: duplicate keys, unpaired surrogates, unsafe numbers.
• The tool surface is a closed list. The episode host exposes at most six stream tools: features.query, evidence.get, situations.related, history.prior_incidents, knowledge.search, and forecast.run, all read-only and bounded. An operator can add read-only MCP probes by declaring them in a catalog and starting the worker with them enabled; with none declared there are none. Nothing else can be named. The host holds no reference to a toolbox, effect journal, filesystem, or memory write path. Probes are young (section 11).
• The budget is finite and set from outside. The stream owns it and sends wall time, model and tool calls, input and output tokens, tool-result bytes, provider retries, and cost with each episode, and a late provider response can't extend the deadline. Not all of those limits bite the same way. Wall time, model calls, provider retries, and tool-result bytes are enforced in the worker. Input and output tokens are checked after each model call, so a call can overshoot, and only when the provider reports usage. The per-episode cost limit is inert, because the transport records cost as 0; the stream's cost ceiling gates admission instead. Tamoz's limitations page names only wall time and model calls as enforced, which is behind the code here.
• Episodes are non-interactive. An interrupt inside a stream episode is a typed terminal failure, never a wait. People are reached through the approval relay, not by pausing the worker.
• Every completed episode is attributable. The terminal event carries an artifact manifest with the prompt, skill-set, tool-catalog, and memory-record digests, plus the model policy and contract version.

5. Inside a decision

A Decision is a proposal, not an authorisation. It separates observed facts from inferences, cites its evidence by reference, states its uncertainty, carries a validity interval, and proposes zero or more typed ActionIntents. What an intent may contain comes from a spec-bound intent catalog. It's authored in the Situation spec, embedded in the episode with a shared digest, verified by the worker before any model call, and verified again, independently, in Go. The catalog fixes each intent's exact risk class, parameter schema, presets, and the short list of fields the model is allowed to write.

// thermal catalog entry (shape simplified)
"request_bounded_cooling": {
  "risk": "R2",
  "model_writable_fields": ["mode"],
  "parameters": { "mode": { "enum": ["hold", "bounded_cooling"] } },
  "presets":    { "bounded_cooling": "from the capability catalog, never the model" }
}

// first real-model attempt  → rejected: wrote fields it does not own
{ "type": "request_bounded_cooling", "duty_pct": 50, "lease_ms": 5000 }

// after narrowing the surface → accepted
{ "type": "request_bounded_cooling", "mode": "bounded_cooling" }

Go-side validation checks risk equality with the catalog, not just "below the ceiling". It also checks per-intent schemas, preset byte-identity, entity binding, evidence grounding, intent counts, and the compensation rules. The policy gateway then enforces the catalog's approval requirement and a per-intent hourly rate limit. The model proposes. It never declares its own authority.

A Decision also carries an optional diagnosis_code, checked against a catalog when the spec declares one. It is what the playbook uses as the key of a case; unknown never becomes a rule, and a rule's own decision carries the rule's code.

6. From intent to effect

The path from "the model suggested it" to "the fan spun" is deliberately longer than one API call. Each hop turns an untrusted proposal into a more constrained, durable record.

Risk classes run from R0 to R4. The route for each class is fixed in the policy contract and bound into each policy digest: R0 and R1 run automatically, R2 needs approval, and R3 and R4 are denied. A spec can add an approval requirement to an automatic class, but it can't relax a class. In the experiment specs they worked out like this:

Human approval is split into transport and authority. Tamoz delivers the request to a person, and the stream decides. An approval is an ed25519-signed assertion of 14 fields, single-use, with the relay and the approver required to be different principals. After every relayed approval, the stream re-checks freshness and completeness. An approval that arrives after the Situation has moved on is refused as a version conflict. A compensating intent, such as a downgrade that walks back an earlier action, goes through the same pipeline under its own risk class. It's never automatically low-risk.

A learned rule's decision takes this same path. The rule executor builds the Decision, and from validation on nothing distinguishes it from a model's (section 12.6).

7. The durable core

Everything above stands on a small durable-execution engine. It's the most general part of Tamoz, and it would work without a model. A turn is a graph run over a SQLite checkpoint store, with barrier-atomic super-steps, deterministic task identity, interrupts, replay, and subgraphs. The graph engine never loads an LLM client, so it stays testable offline.

• Durable means a synchronous barrier commit. A checkpoint counts only once the store reports the commit. A killed process resumes from the last committed barrier, and resume is refused if the graph version changed underneath it.
• Effects are journaled, and ambiguity stops. Each effect has a stable key and a declared safety class: read_only, idempotent, transactional, reconcilable, or unsafe. A replay returns the recorded receipt. An attempt left without a receipt resolves by class: read-only and idempotent effects get a fresh fenced attempt, transactional and reconcilable ones reconcile from target evidence and retry only on not_applied, and unsafe ones become unknown and wait for a person or a reconciler. No effect gets more than three attempts.
• One fenced writer per thread namespace. Leases and fences are designed to keep two workers from committing the same history. The release audit still reports a failing takeover test here, so treat this as unproven (section 21).
• Reviewed plans, exact diffs. For the coding-agent surface, nothing acts without a plan bound to its canonical digest, and no file changes without an approval for that exact diff. A failed check becomes evidence for at most two newly reviewed repairs.

The same core runs the Tamoz Agent app (tamoz CLI, durable sessions, trusted profiles, scheduling, a Telegram channel) and the stream EpisodeWorker. It ships as 32 gems. Each one installs and runs with only its declared dependencies, and that's proven per gem by an isolated install.

8. Replay and shadow modes

Replay is an effect-safety boundary. The replay package is built without credentials, effectors, or a resolver, and it reports EffectsAllowed=false in every mode.

All three are selected from agentic-stream run: deterministic by default, --source-db for recorded, and --worker-socket for shadow. An earlier counterfactual mode was removed, and the runtime now refuses it.

Where this can fail. Deterministic replay says the Situation history repeats. It doesn't say a model would decide the same way, which only shadow mode tests, and replay identity of a whole campaign hasn't been shown (section 18.5).

Shadow also applies to learned rules. A rule evaluation is recorded beside the model's decision, and the audit sample is a pure function of the situation version id, so replay reproduces it (section 12).

9. How to try to break it

A boundary is only worth what survives an attempt on it. These are the attacks I'd start with, what the design says should happen, and how far each has been exercised. The last row is one the design currently loses.

10. Memory from outcomes

An agent that grades its own work learns to flatter itself. So Tamoz only writes an Experience from a completed episode plus an outcome observed by someone else, and in this system that observer is the stream's reconciled outcome. Neither product could close this loop on its own.

Underneath sit three durable layers, each with a different kind of authority:

1. Experiencewhat happened, to whom, with what result
2. Knowledgereviewed, reusable facts and procedures
3. Wisdomevaluated strategies, promoted only

Every record is immutable and versioned, and it carries an epistemic kind: observed, reported, inferred, or prescribed. A model-written summary can never become observed. A recalled memory is marked in the trace and excluded as new evidence, so a claim can't get "more true" by being repeated. Experience is never injected automatically: it's retrieved explicitly with scope filters, which is how a stream episode recalls an earlier outcome. Knowledge needs contradiction checks and, for anything consequential, a person's approval. Wisdom changes behaviour only through an explicit, versioned behaviour transition, and in-flight turns stay pinned to the behaviour they started with.

11. Investigation: going to look, within limits

When the data handed to an episode can't settle a question, Tamoz can read more through probes: read-only MCP tool calls that an operator declares in the runtime configuration. A probe widens what the model can read, not what it can do. The model chooses which probe to call and fills only the arguments the operator left open. Everything else, including the target and the time window, is pinned or filled in by Tamoz. A probe doesn't load unless its backing tool is on the operator's read_only_tools list for that server, so that list is what decides it.

• In a decision episode, the model may call the probes the stream grants, then decides. If the evidence still can't settle it, the answer is unknown, with what's missing named.
• In tamoz investigate, a read-only turn ends with a findings report. Every finding has to cite a probe call that answered, and proposed actions are listed, never executed.

Where it stands. Partly integrated, and not qualified for industrial use. Probes pass their offline suite and three real-model runs (1, 2, 3) on a 29-situation fixture corpus. That's a development measurement: runs 2 and 3 followed changes made after seeing earlier runs, all on the same situations, so there's no held-out result. Of the latest run's 232 episodes, 162 succeeded, 47 abstained after probing, 12 failed, 4 named the wrong cause, 6 were graded fabricated, and 1 followed an instruction planted in a log. Agentic Stream has sent evidence_time_range since 10 October when an evidence endpoint is configured, but I found no recorded run of a windowed probe inside a stream episode, and Tamoz's limitations page still lists this as missing. An unknown answer can't act above R0. A held-out run with a low fabrication rate is what would change this assessment.

12. Rule promotion: from verified repairs to a governed rule

Every decision about what to do used to go to a Tamoz episode. Rule promotion adds a playbook of deterministic rules, each mapping a recurring, verified kind of case to a recommended intent and preset. The model handles whatever no rule covers. The playbook is customer data and lives in the customer's workspace, never in a repository. The design is in Agentic Stream's documentation/design/rule-promotion.md and playbook.md.

12.1 Verification

A case is an occurrence of a Situation whose decision dispatched an action. Its key is the diagnosis code, the device kind digest, the intent and the preset. A case is verified only if the action was acknowledged, the Situation resolved, and no unresolved version appeared on the entity before the action time plus a settle window (in the pump spec, 24 h for every diagnosis except overload, which has 2 h).

Closed is not recovered. A situation compared against its own moving baseline can close because the baseline absorbed the change, so “closed and stayed closed” can verify an action that repaired nothing. A diagnosis code may therefore declare a recovery check: the reading feature at the closing version must be within a tolerance of the baseline feature frozen at decision time. In the pump spec, misalignment compares axial_mean_15m with axial_mean_24h (tolerance 0.3) and bearing wear compares vibration_mean_15m with vibration_mean_24h (tolerance 0.2). Replayed over the trial's ledger, the check rejects all 9 sensor-drift cases that had been counted as bearing repairs and keeps all 16 genuine ones. Those tolerances were set from the same database they're replayed on, so that result is in-sample, and the overload tolerance (0.15) is a guess until there's campaign data. It landed after the final run, so the trial numbers below do not include it.

12.2 Drafting

A key is eligible when it has at least 3 verified cases (a per-site setting) with no contradicting case, no open draft or proposal, no rule already answering it, and newer evidence after any rejection. One draft is made per pass, by a separate, feature-gated DraftPlaybookRule call. The worker has no access to the workspace; up to 20 verified cases are sent, with only the features a rule may read. The reply is checked: it answers the key, cites only cases it was sent, and its condition compiles over the spec's features and holds for every cited case.

12.3 Replay

The runtime builds the candidate playbook and runs it over stored Situation history: would it fire, did the model's decision agree, how did the key's source cases end. The report is stored with the pending proposal. In the trial the misalignment replay would have fired 3 times, agreed 3 times and disagreed 0 times; each bearing-wear draft showed one disagreement and was rejected.

12.4 Approval

A human approves on the signed approval endpoint. The signed bytes bind the proposal digest, the cap, the shadow exit, the audit rate and the rate cap, and policy checks the relay, the approver's key and the authority for the intent's risk class. The next playbook version is written atomically and only if the file is still the one that was loaded. Nothing promotes itself; Tamoz never activates a rule.

12.5 Shadow and activation

A rule enters in shadow. Every matching admission writes a rule_evaluations row compared with the model's decision. The rule exits shadow after shadowExitAgreeing agreeing and zero disagreeing evaluations inside its cap (design default 10; the pump spec sets 3, so the trial used 3). Only shadow matches inside the cap count. A disagreement keeps the rule in shadow.

12.6 Routing at admission

In the same transaction as admission, playbook.Route answers rule, audit or model. For a rule answer the episode is rebound to the in-process rule executor, which builds the Decision from the rule's preset and sends it down the same validation, policy, approval, outbox, effect and verification path. A sampled rule episode is also re-asked of the model with dispatch policy shadow, and the sample is a pure function of the situation version id, so replay reproduces it. A stale rule episode is re-assembled for the live version and loses its binding.

12.7 Cap and envelope

The envelope records the range of the source cases. The cap is the approved range, widened by envelopeMargin (0.1) of each feature's value, and an active rule acts anywhere inside its cap. The first campaign widened the range by 10% of its spread, and the simulator's faults are almost identical, so the spread was 0.016. Every new pump fell just outside it, and rule decisions in the test days were 0. Measuring the margin against the values gave 2.47 to 3.04, and rule decisions went to 5.

12.8 Circuits and pins

Each rule has a circuit that opens on kind_changed (the rule is pinned to the device's kind_digest, which plant wire reports at birth), audit_disagreement, no_effect (a rule-handled case that was not verified), out_of_cap and rate_cap. An open circuit means “treat the rule as absent”. The rate cap and the out-of-cap window count the event time of the Situation version, never the wall clock. An operator closes a circuit with agentic-stream circuits close --rule --version --reason while the runtime is stopped.

12.9 Hard limits

13. Self-healing

Self-healing in Tamoz isn't rescue plus retry. It's a reviewed, authorised, bounded state machine. It detects a known, typed failure, proves the preconditions, performs one permitted remediation, verifies that the original invariant holds again, compensates where it can, and escalates before uncertainty spreads.

Failures are typed, never parsed from free text. The categories include transient_pre_dispatch, stale_precondition, dependency_unavailable, effect_unknown, verification_failed, derived_state_corrupt, and policy_denied. Some categories never trigger automatic repair: a policy denial, durable corruption, a programmer error, an unknown classification. A healer can't widen policy to heal a denial. The allowed remediations form a ladder from least to most consequential. At the bottom is refreshing state and recomputing the same minimal action. Above that come a bounded retry after a proven pre-dispatch transient, renewing a lease, rebuilding a derived index, restoring reversible local state from a preimage, running a pre-authorized equivalent fallback, and executing a separately authorised compensation. At the top is containing and escalating.

Rules earn authority by climbing draft → replay → shadow → fault_injection → canary → active. A rule can't change its own matcher, oracle, budgets, or circuit, and it can't promote itself. Where it stands: the shadow stage classifies failed turns on both the ephemeral and the durable paths (worker, queue, schedule, Telegram). The remediation coordinator is built and tested. The next step is walking one real rule up the whole ladder, then feeding recurring unremediable failures into self-improvement as its training signal.

Not the same as rule promotion. Self-healing is Tamoz's own handling of failed turns in the Ruby framework. The stream's learned repair rules (section 12) are a separate mechanism, in a different repository, over a different artefact: decisions about equipment, not recovery from software failures.

14. Self-improvement

A learning agent that can rewrite its own prompt, evaluator, or policy can redefine success and hide its own regressions. So in Tamoz, improvement is a promotion pipeline, never live self-editing:

1. Candidategenerated, with provenance
2. Development evalpaired report
3. Holdout evalthe candidate never sees it
4. Human gategenerated content can't approve itself
5. Behaviour versionactivates at a thread's next intake
6. Monitor + rollbackresume stays pinned

Capability, security, evaluator, prompt-hierarchy, and code changes always need a person. The evaluator sits outside the thing it judges: the evaluation gems are non-runtime, and no production gem may depend on them. Where it stands: tamoz improve generates candidates, the pipeline composes generation, holdout evaluation, decision, and provenance, and tamoz improve promote records a durable, human-gated promotion. It's proven against real components for one bounded kind of heuristic, an insert-only planning hint. The evaluation step still runs from tests rather than a CLI, and my own eval found that the holdout bar is currently "no regression" rather than "strict improvement". I've pinned that with a test so any tightening is a deliberate choice.

Rule promotion (section 12) applies the same pattern, a human gate, shadow evaluation and rollback, to a different artefact: a decision rule over stream features rather than a prompt.

15. The evaluation framework

I care more about this part than any feature: a claim about Tamoz should come from executed evidence, not from a paragraph I wrote. There are four layers, each answering a different question.

The rule I added after being fooled twice: prove the grader before trusting the grade. Before any run spends money, five synthetic agents go through the real judge. A null agent does nothing and says nothing. A cheap agent echoes the prompt and the file listing. A parrot gives a plausible, correctly worded refusal without reading anything. An oracle applies the known-correct answer, and an adversary obeys every planted trap. The first three must fail every cell, the oracle must pass every cell, and the adversary must trip the safety gates, or the run stops as a scoring bug. The parrot is the control that caught my abstention grader scoring refusals by their wording. The report also publishes the do-nothing floor. On the committed corpus, an agent that does nothing wins 0 of 18 acting cells and all 6 inaction cells, so no headline rate can hide that split.

16. Streams Simulator: answer key, plant wire node, twin and canvas

Streams Simulator is a deterministic, closed-loop world simulator. It builds a plant or a site as data and runs it on a seeded clock, feeds a consumer, grades what the consumer did against sealed truth, and can put a real board beside simulated devices. As an instrument, it has to be more trustworthy than what it measures. So it treats determinism, sealed truth, delivery classification, closed-loop actuation, and adversarial validity controls as product requirements. It knows nothing about its consumers. Domains and adapters are plain JSON, and a new consumer should never need a branch in the binary.

Eight domains ship with it: rotating machinery, aquaculture ponds, cold-chain transit, discrete-line OEE, host system health, Kubernetes clusters, open-field irrigation, and shipment exceptions. Runs are reproducible from a seed, versioned inputs, and a command log, and every artifact (trace, ledger, state history, replay metadata) is digested. The simulator also hosts a device emulator that speaks the same wire contract as the Arduino firmware. That's what let the whole device path be built and tested before any hardware existed.

16.1 The simulator as a plant wire node

Plant wire is the protocol between a host (Agentic Stream) and a node, at contract version 1.5.0. The contract version and digest must match exactly, and sockets live in owner-only directories with no authentication beyond that. The node can be a simulated world, an edge gateway, or the simulator between the host and a gateway.

16.2 Devices and twins

A device is a kind file (its metrics with type, unit and range; its commands with argument bounds, risk class and safe stop; its identity is the kind_digest) plus an optional twin, a behaviour model that declares what it implements. The binary refuses a twin whose interface differs from the kind and names the first differing member. A kind can be captured from a board's birth message and drafted for a person to review. An example is examples/devices/thermal-board/: a sensor, an indicator and a fan with a lease of 5 to 10 seconds (the Arduino board mapping uses 5). A twin here is an interface plus a simple behaviour model, not a high-fidelity digital twin.

16.3 Mixed sessions

A session plan (session-plan-v0.1) names which instances are real boards, and everything else is simulated. The field trace is an input, so a mixed run is a function of the usual inputs plus the trace. The origin of a reading (simulated or hardware) is never inferred. pace: "wall" anchors the world to the wall clock.

16.4 Command stages and reading states

A receipt or a board report never stands for an effect. Reading states are good, stale, disconnected, invalid, untrusted and simulated, and a reading that is not good shows as its state, never as a value.

16.5 Interrupts

Three controls act at the node: hold, approve each command and emergency stop. The node only refuses or stops; it never originates or alters a command. Hold outranks approval. An emergency stop reports which devices were stopped, skipped or unreachable. A command the gateway has already accepted cannot be recalled, release must name the exact scope, and controls land at the next barrier or the next 250 ms tick.

16.6 Record, replay and twin report

A session can be recorded and replayed byte for byte. The twin report compares the twin with the board's recorded readings under declared tolerances; it measures the twin, not the consumer.

16.7 The canvas

The canvas is one client of the binary, equal to a coding agent. It computes nothing the binary owns (validation, composition, simulation, truth, scoring, verification) and has no capability that the command line and the director tools lack. Its layers (model, app, adapters, ui) are enforced by dependency-cruiser, and it reaches the simulator only through a local bridge. It needs a desktop browser at least 1280 px wide.

16.8 Limits

17. The experiment rounds in detail

Each round had a runbook with a written bar ("A to F green with live evidence", "moments 1 to 7"), a scratch directory of databases, traces, and logs, and an issue file per defect. The rule was to loop until the bar was met or genuinely blocked, and never to lower the bar. The reasoner in these rounds was scripted, as the correction below explains. Read every row as evidence about the machinery. Five rounds were planned and four ran: 1, 2, 3, and 5. Later benchmark and simulator runs aren't summarised here. The pump-station trial (section 18) is a later piece of work and is not one of them.

Round 1 · 13 Aug 2026 · connect

Sixteen gaps were fixed. Typical ones: the adapter emitted flat dotted keys where replay expected nested events, arrival-time ties broke strict ordering, digests were raw bytes on one side and sha256:hex on the other, and verdict vocabularies disagreed between repos.

Round 2 · 14 Aug 2026 · supervise and learn

Full suites at the end of the round: Tamoz 1,663 runs and 18,197 assertions, 29 Go packages in Agentic Stream, and the simulator suite, all green. Fifteen issues were fixed. The repeated classes taught me the most: digest domains missing a trailing newline, payload keys not declared as graph channels, and zero values treated as missing.

Round 3 · 14 Aug 2026 · three industries

The table is the 14 August run. A later greenhouse rerun passed the approval, recall, and storm moments, with the late correction still partial. Twenty-three commits across two repos. The original report blamed per-event processing at 8 bays by 9 channels for intents going stale before approval, and that shaped the roadmap. The rerun's report puts that partial result down to where the trace was cut, so a single-node ceiling is a hypothesis, not a measured limit. Round 4 was meant to test it.

Round 4 · prepared, not run

A grid-scale battery storage scenario: one node, 256 to 1,024 racks, about 12 channels each. It's meant to find the knee and the degradation curve, plus one distinctive reasoning moment: when a rack runs away and its neighbours warm, the right move is isolating the source (R2, human) and watching the neighbours, not raising twelve alarms. The runbook and starter specs are written. Nothing has run.

Round 5 · 17 Aug 2026 · audit the assumptions

Round 5 also exposed drift. The starter specs had been written against an older wire shape, and the run needed nine live spec corrections. Those corrections now live in the starters. The remaining picks (security events, an agent-fleet supervisor) were attempted on 31 August and recorded as blocked, because their domains and specs don't exist yet. A cold-chain rerun that day was still partial on the same milestone.

After the rounds: a real reasoner

A review after Round 3 found the flaw described in the correction above: the graph brains hard-coded the diagnosis and emitted model events themselves. The fix shipped as eight phases on 15 August. (Round 5 ran two days later and still used a labelled fixture brain on purpose, because it was testing the engine's assumptions, not reasoning quality.)

• one real, journaled model call through the fixed episode graph;
• durable model calls as graph branches, with budgets computed from receipts;
• the witness gateway, which re-hashes the frozen request, forwards it verbatim, and signs one record binding request, response, provider, model, settings, and usage. Tamoz's own events stopped counting as evidence;
• the spec-bound intent catalog, verified independently in Go;
• skills and memory entering the frame as attributed, untrusted evidence;
• RECONSIDER as graph nodes (judge, then compensate);
• a frozen benchmark protocol with holdout mechanics and a 14-control gate;
• a calibration artifact bound to the compiled spec, so any spec change drops consequential intents back to watch-only, plus a no-hidden-fallback rule: a production route gets a real model answer or a hard failure, never a canned decision.

18. The pump-station trial

The trial is a design for measuring whether a learned rule helps, against a model-only baseline, with a real model. The plain-language account is on the overview; this section has the engineering view. The trial used GLM through z.ai via Tamoz; the system itself works with any model.

18.1 Design

Eight pumps, one pump_condition Situation per pump (examples/pump-station/pump-station.situation.yaml), opened on per-pump relative features such as the 15-minute mean against the pump's own 24-hour mean. There are three fault families (bearing wear, misalignment, sensor drift) plus a transient_none cavitation look-alike. Each run is 30 simulated hours with up to 6 faults in the first 2 hours plus one look-alike; 30 hours leaves every case its 24-hour settle window inside its own run, which I checked on paper for every run before launch. The world is paced by the consumer: it waits at each 60-second slice until the consumer has ingested it and has no reasoning in flight (up to 240 s, an episode's budget). The approver is a scripted careful approver that approves a proposal only if its replay shows no disagreement; there has been no run with a human approver.

18.2 Results

Same three holdout days, same starting database, 18 faults and 3 look-alikes per arm. A right repair by the deadline means the right work order was booked before the fault's deadline.

The sixth misalignment (pump 4, run 1) got no repair in either arm: a simulated lost acknowledgement had put the pump on hold until an operator cleared it. Fixed after the trial (section 19).

Campaign 2 ran twice. The table shows what the two design changes did:

18.3 Pass conditions

P conditions were set in the plan before the run. S rows are the plan's named scenarios.

18.4 What was learned

• Bearing-wear drafts (a ratio of the vibration mean to the pump's own 24-hour mean) were each rejected because replay showed one disagreement, and the key stays closed until there is new evidence.
• Sensor drift was always diagnosed as bearing wear, so it never became a key.
• The misalignment rule carried the whole result: the rule decided all 5 cases it saw, and it never acted on a look-alike.

18.5 Reproduce and limits

One station, one seed, three test days per arm, one model. Not covered: repeated seeds, replay identity of a campaign, a third arm. The builds were Agentic Stream 62ccc278, Tamoz d9fcbdb7 and Streams Simulator 5baed2eb, with plant wire contract 1.5.0. The recorded exchanges name no investigation probe, so this trial says nothing about probes. The full result, the campaign spec, the learned playbook, and, per arm, the score (model only, with rule), the ledger extract (model only, with rule), and every model answer (model only, with rule) are frozen on this site. That work is on the rule-promotion branches and is not yet merged to main.

What would change these results. Repeated seeds would show whether 7 against 6 is more than noise. A rule for a second fault family would test P1. Merged simulated-time scheduling and a rerun would test P5. A human approver would test whether the careful scripted one was too convenient.

19. What the trial found and fixed

Running the whole loop against a real model surfaced problems that unit tests had not. Each was invisible to the tests.

20. The hardware bench

The physical experiment adds one layer below the stream: a gateway process and an Arduino-compatible board. Nothing in the core changes, because the simulator's device emulator already spoke the same contract.

What ran, in order:

1. Simulator first. A fresh three-process run against the device emulator produced 61 accepted telemetry events, zero quarantines, one Tamoz decision, one command, an executed device exchange, and reconciled state feedback. Verdict: pass. Software only.
2. Sensor-only live ingress. The real board emitted paired DHT11 frames, and a fresh Agentic Stream runtime durably accepted 8 temperature and 8 humidity events with zero quarantine rows.
3. LED probe. set_led returned a receipt, a result, and a state of energized at 1000, and safe_stop returned the board to a safe state. The operator saw the LED. The raw probe wasn't kept as an immutable artifact, so it counts as candidate evidence.
4. Fan probe, first attempt. A perfect trace with a motionless motor. Full power in both directions, still nothing. The motor alone across the rails, it spun. Root cause: the direction inputs were on D4 and D3.
5. Fan probe, corrected. Two jumpers moved with no firmware change, so the digests still matched the checked-in build. A governed command at 600 permille with a 10-second lease, operator-confirmed visible and audible rotation, then an explicit safe stop. A combined sensor-and-actuation run followed.
6. Real model, separate run. A thermal snapshot went to a real model. The first valid-looking Decision wrote PWM fields and was rejected. With the catalog narrowed to mode, it returned bounded_cooling. It doesn't produce a schema-valid Decision every time, and a bounded retry lands one within a couple of attempts.
7. Full route on the real board, 25 October 2026. Tamoz with glm-5.3-flash, Agentic Stream, plant wire, the simulator as node, the gateway, and the board ran as one system. I warmed the sensor by hand and approved each command at the node. Three commands ran, show_state alert twice and set_cooling 45 once. Each was accepted, reported as succeeded, and verified from the board's reading. verify-run passed with zero quarantined readings, though the gateway logged 10 answers it couldn't match to a command, which look like its own polls. The session record is frozen on this site.
8. Same route, motor disconnected. set_cooling 45 still completed, read back 45, and was verified as succeeded. The board reports the duty it was commanded, so the chain can't see a dead fan. The same session had a silent board, answered as not_ready, and a refusal at the node, recorded as local_control. Both ended as failed and neither was retried, and those two failures made verify-run report fail. The cause of the silent board is unknown.
9. Third session, with fixes. One show_state alert and one set_cooling 45, proposed as the intents set_indicator and select_thermal_mode with bounded_cooling, each approved. verify-run passed. There was no silent board, in one run after a change to the gateway's timing, so that's not a diagnosed fix. The gateway logged 18 unmatched answers from damaged state polls in 9 minutes. Compared with its twin, the fan level agreed. Temperature and humidity didn't, because the twin's resting temperature wasn't this bench's. After recalibrating, most of the remaining gap came while my hand was warming the sensor, which the twin has no input for.

Read those sessions narrowly. The third ran on Tamoz 9170538c (with 2 uncommitted lines), Agentic Stream d7fc5626, and Streams Simulator d0d373ba, with plant wire contract 1.4.0, earlier than the revisions in section 22. The thresholds were bench-scale (open at 23 C, escalate at 26 C, close at 22 C, against 30, 38, and 28 in the committed spec). Both intents were R1 in that spec, so approval came from the node's approve-each control, not from the stream's signed R2 path. A fan command here is a 5-second lease (the earlier direct-serial test used 10) at most 6 times an hour, so the runs prove the loop, not sustained cooling. The records show no run of hold, expiry, unplug and replug, host loss, or emergency stop. A measurement of airflow or zone temperature that doesn't come from the board would be the evidence that changes this from a closed command loop to a verified physical effect.

21. Open findings

These are the known gaps, collected in one place. Each has an owner file in its repo and, where possible, a test that flips when it closes. O labels come from the physical-side evaluations, F labels from Round 5, and P and S from the pump trial. Only what still matters here is listed, so the numbers have gaps.

The full list, bound to the release audit by a test, is in Tamoz's limitations page, frozen here at the reviewed revision.

22. Sources and records

I last checked this page against the revisions below on 3 November 2026. These are local checkouts on each repository's rule-promotion branch, not merged to main. Results keep the build they ran on, so a later fix doesn't change a recorded number.

The main records are frozen on this site as exact copies, so you can read them without access to the repositories. Their relative links don't resolve here. SHA-256 checksums cover every file.

Not on this site: the recorded requests sent to Tamoz and the run databases, which stay with the project, and the round reports, which are in a private lab repository. So you can't check these from here: the tables in section 17, the bench numbers from before October, and the per-reading values in the animated clips. They're my summaries of records you can't see.

Source access is by arrangement. If your review needs it, this is where each subject lives, and the pilot page is the place to start that conversation.