DEV Community: pawel jankes

Universal Lab: turning an AI research meeting into a live, inspectable experiment on modest hardware

pawel jankes — Wed, 07 Oct 2026 14:09:33 +0000

SSI Universal Lab — Partner Meeting Start Here — 2026-10-07

Purpose: concise entry point for external researchers and meeting participants
Current boundary: installed Universal Lab baseline + verified preparation + clearly separated R5 integration work
Private boundary: proprietary SSI source code, credentials, private prompts and reconstructive runtime internals are not published

This is not intended to be a conventional video call

Universal Lab is being developed as a research-meeting environment in which invited participants can talk with the SSI Director, observe bounded SSI processing, and inspect evidence from the same session.

Universal Lab is the outer research-collaboration environment. It is the wider SSI workflow that brings external researchers into a structured, inspectable meeting format.

ZeroLab is a separate internal bounded experiment/validation layer used within the wider SSI workflow. ZeroLab is not a rename of Universal Lab — it is a distinct layer that provides bounded laboratory/runtime capabilities that feed into evidence and validation during meetings. Universal Lab R5 is intended to expose bounded ZeroLab session/validation information during research meetings without merging ZeroLab into the chat UI.

The current meeting model is built around Paweł, Sara and Leire and is intended to combine:

Conference video/audio presence;
One shared chronological meeting timeline;
Directed participant chat;
Director interaction;
Safe CZARA / Shadow status events;
Router V10 / Micronetwork telemetry;
BODY_FROZEN execution visibility;
ZeroLab validation;
Evidence/provenance generated from the session.

The target result is that a research meeting can be inspected afterwards as a bounded evidence package rather than remembered only as a presentation.

Why Universal Lab was built

Universal Lab was built to turn external research meetings into inspectable SSI sessions instead of ordinary video calls or slide presentations. In a conventional meeting, what happens is largely ephemeral — a recording may exist but the actual processing, reasoning, and evidence trail is opaque. Universal Lab makes the SSI processing observable alongside the human conversation, so that every interaction has a bounded, inspectable record.

The immediate planned use case involves a meeting with Sara and Leire from TECNALIA. This is a planned research meeting to demonstrate the inspectable-meeting format with external partners. This planned use case does not imply endorsement or validation by TECNALIA or its personnel — it is an invitation to explore the SSI meeting format.

What already exists

Universal Lab baseline

The operator baseline is Universal Lab Live Gate R3 / 1.1.1.

The installed baseline includes authenticated web access, persistent SQLite-backed accounts, and a localhost-first deployment path. The current named accounts include Paweł, Sara, and Leire.

ZeroLab

ZeroLab V2 already exists as a separate bounded laboratory/runtime layer. Its earlier local pilot evidence is published elsewhere in this repository. Universal Lab R5 is intended to expose bounded ZeroLab session/validation information during research meetings.

SSI knowledge preparation for CZARA / Director_Czary

The prepared knowledge path currently records:

345,961 indexed documents;
1,432 prepared curriculum cases (prepared and NOT RUN);
48 selected DIRECTOR_SSI_V5_TO_DIRECTOR_CZARA source artifacts;
48 selected BODY_FROZEN_SSI_V5_TO_BODY_FROZEN_CZARA source artifacts;
Knowledge state INDEX_READY;
Qualification NOT_RUN.

This means the Director_Czary/CZARA knowledge path has been prepared from existing SSI material, but this repository does not claim that every private skill has already been live-qualified through Universal Lab.

Designed around the actual modest development computer

Universal Lab is deliberately being adapted to the real local machine instead of assuming a datacenter GPU. The target hardware is:

MSI GV62-8RE laptop;
Intel i7 processor;
16 GB RAM;
GTX 1060 6 GB VRAM;
Ubuntu Linux;
Ollama runtime;
Local qwen3:4b model.

This is a resource-bounded design. The integration strategy is:

Local-first execution;
Avoid loading several large models simultaneously;
Reuse one local LLM through role-specific calls where practical;
Keep event handling, session state, retrieval/prefetch, and other light work away from scarce GPU memory;
Use text as the common fallback when voice/video components degrade;
Reserve cloud inference for fallback/escalation rather than making the meeting dependent on a large remote model.

The hardware constraint is part of the research/engineering context: the goal is to demonstrate that the full meeting workflow can be made usable on a relatively modest local computer.

Translation bridge and measured host behavior

The current R3 configuration contains a local translation command bridge using:

translation
  -> command_json
  -> python module
  -> translation_ollama

The development host uses local Ollama with qwen3:4b.

A recent operator-side test reported roughly 2 seconds for the local translation step on this host. This is explicitly recorded as a host-specific observed value, not a universal latency guarantee or an external benchmark. It does not imply performance on any other machine or with any other model configuration.

The intended meeting pipeline keeps translation parallel to SSI processing so the Director/CZARA path does not have to wait for a human-facing Polish translation before it can start context work. This supports multilingual Polish/English/Spanish use in the meeting format.

Current bridge boundary — important

The Universal Lab architecture includes Director, CZARA, Router, Micronetwork, BODY_FROZEN, ZeroLab, and evidence integration points.

However the latest R3 bridge configuration must be described conservatively. The translation bridge is configured, while other native meeting bridges such as Director/CZARA context/STT remain disabled or are awaiting the next binding step.

Therefore this repository does not claim that every native SSI bridge (Director/CZARA/Router/BODY/ZeroLab) is already live-bound through R3.

R5 is the integration step intended to bind and verify the remaining live paths before they are presented as complete. R5 unified live integration is the current next step.

R5 meeting flow

The intended R5 flow is:

Participants (Paweł / Sara / Leire)
        |
        v
   DIRECTOR
        |
        +--> CZARA / Shadow
        |
        +--> Router V10 / Micronetworks
        |
        +--> BODY_FROZEN
        |
        +--> ZeroLab
        |
        v
  Evidence / Partner-Safe Session Package

The technical views remain separate so researchers can inspect different parts of the process without turning the main meeting view into a debugging console.

Key design notes:

BODY_FROZEN is not a chatbot. It is an execution/verification layer — it produces receipts and task output, not conversational replies.
Safe CZARA/Shadow events provide bounded status visibility without exposing internal reasoning.
Partner-safe evidence export means the meeting deliverable can be shared without revealing proprietary internals.

Evidence from the meeting

The target partner-safe meeting export is intended to contain:

Participant transcript;
Translation;
Director interactions;
Bounded CZARA/Shadow events;
Router decisions and timings;
BODY_FROZEN task receipts;
ZeroLab validation;
Evidence references and timestamps/provenance.

Raw audio/video are not required as part of the evidence package.

Current research status summary

Area	Status
Universal Lab R3 / Live Gate	INSTALLED
Persistent web auth/session layer	INSTALLED
ZeroLab V2	EXISTS — bounded evidence published
SSI knowledge index	INDEX_READY — 345,961 indexed documents
1,432-case curriculum	PREPARED / NOT RUN
Translation bridge	CONFIGURED
Recent local translation observation	~2 s on the development host (operator-reported, not a universal benchmark)
Director/CZARA/Router/BODY/ZeroLab native live binding through R3	NOT ALL LIVE-BOUND
R5 unified meeting integration	PRE-BUILD — current next step

Additional status references

Public evidence mirror

A public evidence mirror is available at:
https://github.com/jankes72/SSI_V5

Disclosure

AI assistance was used for editing and translation in the preparation of this article.

Before the GitHub Release: Two Isolated Zero Labs for CZARA and SSI V5 Final

pawel jankes — Fri, 02 Oct 2026 17:29:51 +0000

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.

Before the Mexico Benchmark: CZARA, Offline Director, Independent ISKRA Paths, and 24 Stages of Web Training

pawel jankes — Mon, 28 Sep 2026 12:05:01 +0000

I have just preregistered the next research phase of SSI V5 before the first official robotics benchmark with a research team in Mexico.

This matters because I do not want to describe the system only after seeing a successful result. I want the repository history to show what was planned, what was already implemented, which hypotheses will be tested, and which claims remain open.

SSI V5 is a solo R&D project, but it is organized as a set of separate runtime roles rather than one large chatbot. The public repository is an evidence and review mirror. The proprietary implementation remains private.

The new preregistration separates three different paths:

the core SSI training sequence, S11-S40;
a separate WEB01-WEB24 engineering track;
the Mexico robotics and offline research programme.

They are related, but they are not the same experiment.

1. Core SSI training: S11-S40

The core sequence trains seven independent execution lines:

BODY_FROZEN;
ISKRA1;
ISKRA2;
ISKRA3;
ISKRA4;
ISKRA5;
ISKRA6.

Each stage preserves PASS, FAIL and INCONCLUSIVE outcomes. Only the verified subset is eligible for cross-consolidation.

The intended stage transition is:

stage execution
-> preserve all outcomes
-> export verified subset
-> consolidate compatible competence
-> BODY_FROZEN + DIRECTOR report completion
-> COMMITTED gate
-> next stage

BODY_FROZEN and DIRECTOR receive the same compatible skill payload and Champion state, but they do not become the same agent.

BODY_FROZEN is the technical execution core. DIRECTOR is the planning, coordination, resource and research-communication core. They keep separate runtime, memory, identity and decision topology.

Consolidation transfers verified competence, LEGO packages, evidence and provenance. It does not transfer personality, merge private memory, retrain neural weights, or import the BODY core into DIRECTOR.

The public front door currently contains detailed evidence through S12. Internally, the owner-reported runtime status includes committed consolidations through S16 and later S-stage activity including S19. The later evidence package will be published after the uninterrupted sequence closes or stops.

2. Champion-Challenger is not a “latest answer wins” mechanism

A new candidate does not replace an older solution just because it appeared later.

A reusable candidate is expected to carry:

competence
+ input/output contract
+ LEGO or micronetwork artifact
+ LAB result
+ evidence
+ provenance
+ version identity

It may remain in HOLD until there is a real reason to compare it against an existing Champion.

An earlier S16 snapshot reported complete accounting for 875 BODY_FROZEN candidates:

CHAMPION   = 1
CHALLENGER = 1
HOLD       = 873
SPECIALIST = 0
ACCOUNTED  = 875 / 875

This does not mean there were 875 Champions or 875 active duels. It means SSI retained a large pool of traceable potential competence instead of deleting everything except the current winner.

The formal software-engineering Champion in that snapshot was s10_9769b8e74e6230f29df90218568d4ecf. The active Challenger was s10_97a39fdb193470923d6de3f5f0764412. Both had disclosed validation PASS, accuracy around 0.85 and F1 around 0.82.

Because the disclosed metrics were similar, novelty alone was not enough to promote the Challenger.

3. Reuse before expensive reasoning

The routing objective is simple:

problem
-> search existing competence
-> strong match: REUSE_TOP1
-> weak match: ESCALATE_FULL_FLOW

One observed reuse example had confidence 0.71. A weak match around 0.3065 escalated to FULL FLOW instead of pretending an existing Champion was suitable.

This is important economically. During later training I observed decreasing paid-model token use. That reduction is an observed runtime result, not only a future hypothesis.

What is not yet proven is the complete causal explanation. The decrease may involve validated reuse, cache, local models, provider routing, shorter paths or other factors.

The final analysis will therefore connect:

paid input and output tokens per case;
cost per verified PASS;
model/provider class;
daily cost limit;
REUSE_TOP1 count;
intermediate verification count;
FULL FLOW escalation count;
PASS, FAIL and INCONCLUSIVE outcomes;
time and retries.

The stronger result would be:

lower paid-token use
+ stable or improved verified quality
+ more validated reuse
+ fewer unnecessary FULL FLOW escalations

4. The ISKRA lines are independent trajectories

ISKRA is not only a different label attached to the same agent.

Each ISKRA preserves its own:

training history;
PASS, FAIL and INCONCLUSIVE path;
candidate pool;
Champion and Challenger evolution;
micronetwork connections;
reuse and escalation history;
dynamic affective-state trajectory.

The affective layer is a computational state mechanism. I am not claiming consciousness or subjective experience.

These state variables can change after decisions, successes, failures, uncertainty and feedback. They may later modify risk tolerance, escalation behavior, planning, reuse or Champion selection.

This creates an important contrast.

BODY_FROZEN accumulates consolidated verified competence. An ISKRA may preserve a narrower but highly specialized solution that never became the global BODY_FROZEN Champion.

A future domain-specific task may therefore be solved better by an independent ISKRA trajectory than by the globally consolidated core.

Frozen checkpoints make longitudinal comparison possible:

initial state
-> post-S16
-> post-S40
-> post-WEB24
-> final replay

Earlier FAIL and INCONCLUSIVE cases can be replayed after the complete curriculum. The test is not only whether the outcome changes, but why:

a different Champion;
a different micronetwork;
a changed affective state;
more reuse;
fewer paid tokens;
a different risk decision;
or a genuinely new solution.

Where technically possible, I also want to separate competence evolution from affective-state evolution by replaying matched variants:

initial competence + initial affective state
final competence + final affective state
final competence + initial affective state
initial competence + final affective state

5. WEB01-WEB24 is a separate engineering school

S40 is not the end of training.

A post-S40 hook is installed and self-tested. Its declared gate is:

S40 execution_complete = true
AND S40 consolidation = COMMITTED
AND WEB LEGO = READY
-> WEB01 -> ... -> WEB24

The WEB track currently reports readiness metadata:

24 stages
192 cases
126 LEGO items
15 templates
7 actors
SYNTHETIC_ONLY data policy

The seven actors are BODY_FROZEN and ISKRA1..ISKRA6.

The progression covers reusable web/programming engineering mechanisms, including HTML/CSS decomposition, routing, CRUD, authentication, REST APIs, FastAPI, localization, security and a capstone.

It does not use real company information as training data. The intended boundary is mechanism and architecture extraction with neutralized or synthetic fixtures.

After WEB24, all seven lines can receive the same previously unseen specification for a page, dashboard or application.

The functional objective will be identical. The final implementation may not be.

I want to compare:

visual design;
information architecture;
component structure;
accessibility and security;
selected LEGO and templates;
Champion/Challenger identity;
number of iterations;
token use, time and cost;
functional test results;
blind human visual evaluation.

The research hypothesis is that independent training, micronetwork, Champion-Challenger and affective-state histories may produce measurable differences in architecture, interaction design and visual finish despite an identical functional objective.

Different-looking outputs are not guaranteed. They must be observed and measured.

6. Mexico is a separate robotics research path

The Mexico programme is not WEB25 and it is not another name for the core training.

The planned curriculum contains 48 stages:

38 training stages
4 validation stages
6 capstone stages

It covers drones, humanoids, cross-domain coordination, offline execution, LEGO Navigation, LEGO Space, no-network map exchange and later unseen partner-defined scenarios.

The first Mexico benchmark will intentionally use a simpler baseline:

DIRECTOR
+ BODY_FROZEN
+ OFFLINE_DIRECTOR
+ CZARA
+ LEGO Navigation
+ LEGO Space
+ LAB
+ EVIDENCE

ISKRA agents will not participate in the first baseline.

The first question is narrower:

Can OFFLINE_DIRECTOR execute a bounded mission, reuse validated competence, preserve local state and evidence, build or exchange spatial LEGO fragments, and synchronize after reconnection?

Only after this mechanism works will I compare OFFLINE_DIRECTOR and BODY_FROZEN Offline against independent ISKRA Offline variants.

7. CZARA is context, not control

CZARA is a multilingual research-context and translation layer between the Mexico research environment and SSI.

It should preserve:

original Spanish or English text;
Polish translation;
source session;
verified speaker identity when available;
uncertainty when identity is unknown;
requirements, corrections, decisions and open questions;
confidence and provenance.

CZARA does not directly command robots and does not replace DIRECTOR.

The important distinction is:

verified professor message
!=
unstructured conversation context

A verified message from the professor has known authorship. A live conversation may be a “context soup” containing the professor, students, technical staff and incidental comments.

SSI must not treat every sentence in that stream as an instruction.

The intended chain is:

source
-> original text
-> translation
-> structured context
-> DIRECTOR interpretation
-> versioned decision
-> BODY_FROZEN execution
-> LAB result
-> evidence

If authority or intent is uncertain, DIRECTOR should ask the professor for confirmation before changing a frozen mission.

This is the human-AI co-learning question behind CZARA: can an external team teach and correct the system through conversation without collapsing human discussion into unrestricted execution authority?

8. Two simultaneous R&D conversations

The Mexico panel is designed around two auditable chats operating at the same time.

Professor to DIRECTOR

The professor discusses objectives, observations, evidence and benchmark revisions with DIRECTOR.

DIRECTOR explains what the system is doing, why a test stopped, what evidence exists, and what revision is proposed.

Authorized technical staff to BODY_FROZEN

An authorized technical operator can communicate directly with BODY_FROZEN for diagnosis, bounded technical requests and immediate STOP, PAUSE or SAFE STATE actions.

This avoids unnecessary latency during an active experiment.

DIRECTOR still observes BODY_FROZEN state and events. If BODY_FROZEN stops, DIRECTOR can explain the reason and consequence to the professor without requiring the technical team to manually relay every detail.

The authority boundary is strict:

STOP / PAUSE / SAFE STATE
= direct when authorized

change of benchmark objective or acceptance criteria
= versioned research revision

The technical chat cannot silently rewrite a frozen benchmark.

This is closer to a real R&D laboratory than a single chat window: the research conversation and technical execution conversation can proceed in parallel while sharing an auditable event chronology.

9. Later offline comparison

After the baseline, the comparison may include:

OFFLINE_DIRECTOR with consolidated competence
vs
BODY_FROZEN Offline
vs
ISKRA1..ISKRA6 Offline

One preregistered question is:

Can an independent ISKRA trajectory, using its own training history, affective-state evolution, micronetworks and Champion-Challenger state, outperform the consolidated baseline in selected LEGO Navigation or LEGO Space tasks without internet access?

For an example ISKRA6 comparison:

H0: consolidated OFFLINE_DIRECTOR/BODY_FROZEN is equal or superior.
H1: ISKRA6 is better on predefined quality, stability or efficiency metrics.

No ISKRA is declared the winner in advance.

10. What already exists and what does not

The current owner estimate for internal Mexico implementation and training readiness is approximately 85%.

That is an engineering estimate, not a benchmark score.

Already implemented or prepared elements include the Mexico panel, separate DIRECTOR and BODY_FROZEN chats, contextual memory, role separation, consolidated-skill compatibility, Champion-Challenger mechanisms, laboratory/evidence foundations and the CZARA/offline architecture.

Remaining work includes final integration, authorization, shared event chronology, stop/pause verification, evidence-completeness tests, offline synchronization checks, an internal rehearsal and version freeze.

The official external Mexico benchmark completion remains 0%. Independent external validation has not yet been performed.

11. Why preregister this now?

If the Mexico collaboration later produces seven or ten benchmark revisions, a future reviewer should be able to go back in Git history and see that:

the architecture existed before the result;
negative results were expected to be preserved;
the baseline excluded ISKRA agents by design;
later ISKRA comparisons were planned in advance;
CZARA was context rather than execution authority;
token reduction was measured separately from its causal explanation;
web artifacts were intended for blind comparison after WEB24;
FAIL and INCONCLUSIVE were not supposed to disappear.

The strongest evidence will not be a claim that SSI is “professional.”

It will be the chronology:

preregistration
-> frozen protocol
-> execution
-> PASS / FAIL / INCONCLUSIVE
-> evidence
-> revision
-> replay
-> transfer to a new domain

The public preregistration is available here:

https://github.com/jankes72/SSI_V5/blob/main/MEXICO_PREBENCHMARK_RND_PROTOCOL_20260928.md

The Mexico robotics plan is here:

https://github.com/jankes72/SSI_V5/blob/main/MEXICO_ROBOTICS_TRAINING_AND_BENCHMARK_PLAN_20260926.md

The public repository contains protocols, sanitized results, failures, repairs, hashes, provenance and claim boundaries. It does not publish proprietary implementation, private prompts, credentials or reconstructive internals.

This protocol does not claim completed S13-S40 public evidence, completed WEB01-WEB24 training, completed Mexico validation, physical robotics validation, safety certification, AGI, consciousness or superiority over external R&D teams.

It records the questions before the answers are known.

Building an evidence-first multi-agent system: 720 paired missions, rollback, and strict claim boundaries

pawel jankes — Sun, 20 Sep 2026 15:21:54 +0000

I am an independent R&D developer building SSI V5, an experimental multi-agent architecture focused on evidence, provenance, consolidation, and rollback.

The implementation itself is proprietary. The public GitHub repository is an evidence and review mirror: it contains sanitized reports, run summaries, test artifacts, and reviewer guidance rather than the private source code.

Repository: https://github.com/jankes72/SSI_V5

Why I built it

A multi-agent system can produce impressive-looking output while still making it difficult to answer basic engineering questions:

Which component made a decision?
What evidence supported it?
Did a transferred skill actually improve the result?
Can the system return to a known-good state?
Are reported timings physical response times or only software-flow measurements?

SSI V5 is my attempt to make those questions part of the architecture instead of adding them after the experiment.

Architecture in brief

The project separates two main cores:

BODY_FROZEN — an execution-oriented core with its own runtime, memory, and lifecycle.
DIRECTOR — a separate orchestration and resource-management core, also with its own runtime, memory, and lifecycle.

They are not copies of each other. Validated knowledge can move through cross-consolidation, but their identities and responsibilities remain separate.

The laboratory also uses six experimental agents called ISKRA1–6. The system records consultations, consolidation decisions, provenance, and rollback events. Candidate capabilities are evaluated through a Champion/Challenger process before promotion.

Current public evidence

The public evidence mirror currently records:

S1–S10 training sequence: COMPLETE / PASS
Seven BODY runtimes discovered: 7/7 PASS
Promoted BODY_FROZEN reload verification: 144/144
Post-S10 drone scenarios: 6/6
Post-S10 humanoid scenarios: 15/15
Drone Mother paired families: 12/12
Rescue Robot Mother paired families: 12/12

The dual-mother cross-domain laboratory executed:

60 deterministic repetitions per paired family
720 paired missions
1,440 domain result rows
720 cross-consultations
360 consolidations
360 rollbacks

Reported mean software-flow timings were:

consultation: 2.4896 ms
consolidation: 0.0369 ms
rollback: 0.1170 ms
total software flow: 5.2559 ms

These measurements describe the software laboratory only. They are not physical robot or drone response times.

What I am not claiming

Clear boundaries matter more than impressive wording. This project does not currently claim:

physical-world validation,
safety certification,
production readiness,
independent replication,
universal superiority over other architectures,
AGI, consciousness, or sentience.

The repository is intended to make the evidence reviewable without exposing the proprietary implementation.

What I want to test next

I am looking for universities, robotics teams, AI researchers, and R&D companies willing to define an external validation problem.

A useful pilot would work like this:

The partner supplies a previously unseen problem or scenario.
We freeze the acceptance criteria in advance: PASS, FAIL, or INCONCLUSIVE.
SSI V5 runs the experiment with evidence and provenance enabled.
Failures remain visible instead of being removed from the report.
The partner receives the results, limitations, timings, and rollback/consolidation history.
Nothing is published without the partner's approval.

The strongest next step is not another internal claim. It is an externally defined test with frozen criteria.

If you work in multi-agent systems, robotics, autonomous systems, AI assurance, or research validation, I would value a technical review of the evidence mirror or a proposal for a hard external test.

I am especially interested in:

paid R&D pilots and proof-of-concept projects,
research partnerships,
grant consortia in Poland or Europe,
independent replication or red-team review.

Feedback is welcome, especially criticism of the experimental design or claim boundaries.

Disclosure: AI assistance was used to edit and translate this article. The project claims and numerical results were restricted to evidence available in the public repository.