Current status: implemented locally · 88 offline tests passed · training and runtime integration in progress · end-to-end runtime validation not yet complete · no physical-system validation claimed.
I am publishing this architecture note before the next GitHub evidence release and before reporting experiment outcomes.
The reason is simple: the rules should be visible before the results. If the experiment later succeeds or fails, the acceptance criteria, authority boundaries, and evidence policy should already be known.
What Zero Lab is
Zero Lab is a controlled experimental execution and evidence layer for SSI V5. It is not another language model, another autonomous BODY, or a mechanism for manufacturing a PASS.
Its job is to turn an externally proposed research problem into a versioned and frozen protocol, route that protocol to an explicitly assigned executor, run only bounded operations, and preserve the resulting evidence without rewriting history after the outcome is known.
The current implementation contains two logically isolated scopes:
| Scope | Orchestrator | Executor pool | Main purpose |
|---|---|---|---|
| CZARA | Director_CZARA | BODY_FROZEN 1.0 | Convert expert input into a frozen, auditable experiment |
| SSI V5 Final | Director Final | BODY_FROZEN Final or ISKRA1–ISKRA6 | Execute and compare controlled experiments across independent workers |
Both scopes use the same Zero Lab engine, but their protocols, state, evidence, Directors, memory, and executor lifecycles remain separate.
The common Zero Lab workflow
1. An expert defines the challenge
The starting point is an externally supplied problem rather than a benchmark designed around the system's known strengths.
A useful specification contains:
- the research question and hypothesis,
- initial conditions and available observations,
- operational and resource constraints,
- a baseline,
- a negative control,
- the main experiment,
- measurable PASS, FAIL, and INCONCLUSIVE conditions,
- invalid or unsafe behavior that must terminate or invalidate the run.
Missing information is not fabricated. If the required adapter, data, or measurement does not exist, Zero Lab must report that limitation.
2. The protocol is frozen
Once the specification is complete, Zero Lab creates a versioned protocol identifier and freezes the contract before execution.
The frozen material includes the hypothesis, test structure, repetitions, constraints, evaluation rules, method version, and relevant hashes. Criteria cannot be moved after the result becomes visible.
3. Planning is separated from expected outputs
A planning model may propose an execution plan, but it is not given the hidden expected-output tables. Model prose does not execute the experiment. A bounded parser and compiler convert only allowed operations into an executable plan.
4. A named worker performs the run
The current software implementation supports two bounded adapters:
- record_transform_v1 — an existing restricted laboratory DSL operating only on supplied tables, without arbitrary file, network, eval, or exec access;
- native_micronetwork_v1 — real computation through an existing enabled micronetwork, with an exact network identifier, artifact hash, and explicit feature vectors. Normal usage is recorded, but the run does not silently modify the network weights.
5. Evidence is recorded
The system records the real inputs and outputs, block-level traces, repetition results, assigned executor, protocol hash, method hash, and outcome. Uncertain execution is not silently retried until it produces a favorable result.
A PASS means that the computation satisfied the supplied frozen protocol. It does not automatically mean successful training, independent scientific validation, or validation on physical hardware.
6. History is preserved
A revision creates a new protocol version linked to the previous one. It does not overwrite the earlier result. Failed and inconclusive runs remain part of the evidence.
Scope 1: CZARA + Director_CZARA + BODY_FROZEN 1.0
In the CZARA scope, CZARA supports communication with a professor or domain expert and helps organize the proposed problem. CZARA may help express an objective and hypothesis, but it cannot invent missing criteria or measurement data and present them as expert decisions.
Director_CZARA manages the protocol lifecycle. BODY_FROZEN 1.0 checks whether the specification is complete and performs the bounded execution once the contract is frozen.
If the protocol explicitly permits it, authenticated expert input may also produce bounded Shadow proposals. A Shadow branch cannot replace the main experiment or overwrite its result. It remains a separate proposal and measurement path.
The professor retains promotion authority. Promoting a Shadow proposal creates a new main branch and a new measurement. Revising the protocol produces a new version and preserves the original history.
This design is intended for the planned external benchmark process, including collaboration with domain specialists who can define difficult tests outside my own areas of expertise.
Scope 2: Director Final + BODY_FROZEN Final + ISKRA1–ISKRA6
The SSI V5 Final scope uses the same experimental discipline with a wider executor pool.
Director Final assigns each frozen experiment to one explicit actor:
- BODY_FROZEN Final, or
- one of ISKRA1 through ISKRA6.
The Director manages assignment, limits, versioning, and evidence collection. It does not become the executor and does not inherit the BODY's private memory or lifecycle.
BODY_FROZEN and the six ISKRA workers can therefore attempt controlled problems independently. This creates a foundation for comparing strategies, checking repeatability, identifying regressions, and later running evidence-gated Champion/Challenger evaluations.
The workers do not receive permission to redefine success. They receive the task, allowed observations, constraints, and tools. Evaluation remains attached to the frozen protocol.
Isolation and resource policy
The two groups occupy separate paid execution slots:
- CZARA + Director_CZARA + BODY_FROZEN 1.0;
- Director Final + BODY_FROZEN Final + ISKRA1–ISKRA6.
They share the existing controlled daily budget, but they do not share one identity, one Director core, or one mutable experiment history.
What has and has not been verified
The current package passed 88 offline tests covering routing and limits, Zero Lab behavior, review logic, and installation checks.
The tests exercise the bounded laboratory interpreter and native micronetwork mathematics with controlled fixtures. They do not prove that all live services on my computer are already operating together correctly.
At the time of this publication:
- full end-to-end runtime validation on the user machine is still in progress;
- no physical drone, sensor, or humanoid adapter is included in this Zero Lab release;
- no result from the ongoing training is being claimed here;
- the evidence chain is local and hash-linked, not yet signed by an independent verifier;
- historical training grades have not been changed.
I will publish positive, negative, or inconclusive results only after the live run and evidence package are complete. A successful outcome will not be announced merely because the architecture exists.
Why publish this before the results?
Because an evidence-first system should make its rules visible before it knows whether those rules will produce an impressive result.
This post is therefore a public architectural timestamp and claim boundary. The next GitHub update will contain the sanitized evidence package after runtime verification, without exposing the proprietary implementation.
Public evidence mirror:
https://github.com/jankes72/SSI_V5
Research domain showcase:
https://ssi-rnd-showcase-jankes72.pages.dev/
I am also interested in external researchers proposing difficult, bounded scenarios for autonomous drones, rescue robotics, humanoid balance and recovery, degraded sensing, or multi-agent coordination. A negative result is acceptable; changing the criteria after the run is not.
Top comments (0)