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.
Top comments (3)
Freezing PASS, FAIL, or INCONCLUSIVE before evidence exists is the right boundary. To make the external pilot independently reviewable, I’d freeze a manifest containing scenario and data hashes, acceptance code, seed and environment, and the policy for classifying inconclusive runs, then have the partner sign that root before execution. Can the partner recompute the evidence checks from the public mirror without access to the proprietary runtime?
The rollback numbers are useful, but I'd push on who generates the provenance record that triggers a rollback. If the same agent (or the same runtime) that executed the action is also the one attesting to whether it succeeded, you've got a self-attestation problem hiding inside an otherwise rigorous evidence pipeline — a subtly wrong action can still write a "PASS" provenance entry if the failure mode isn't one the agent itself is checking for. What actually catches that in your setup: is DIRECTOR verifying BODY_FROZEN's own evidence independently (different code path, different signal), or is provenance self-reported by the executing core and only the rollback decision cross-checked? That distinction matters more than the raw pass-rate for anyone trying to reuse this pattern.
The claim boundaries section is the most refreshing part of this. An architecture post that explicitly lists what it doesn't claim — no physical-world validation, no safety certification, no AGI — is rare. Most multi-agent write-ups bury the scope limitations or omit them entirely.
The Champion/Challenger promotion process for capabilities before they get merged into BODY_FROZEN is the piece I'd want to understand better. That's where the interesting engineering decisions live — what's the threshold for promotion, and does a promoted capability ever get demoted if it underperforms in a new domain?
720 paired missions with rollbacks staying visible rather than removed from the report is the data discipline that makes this reviewable. "Failures remain visible" is the line that separates a research artifact from a product demo. The externally frozen acceptance criteria pilot proposal is exactly the right next step.