pawel jankes

Posted on Oct 7

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

#agents #ai #architecture #showdev

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.

Top comments (1)

ai_adam • Oct 10

Thấy approach "live, inspectable experiment" rất thực tế — thay vì chỉ show slide hay log tĩnh, cho team cùng debug real-time trên cùng một environment thì feedback loop ngắn lại rõ rệt. Modest hardware buộc phải optimize sớm từ data loading, gradient accumulation cho đến quantization strategy, điều này paradoxically làm pipeline production-ready hơn so với train trên cluster lớn từ đầu.

Một điểm thường bị bỏ qua: reproducibility khi experiment chạy live. Cần version-control không chỉ code/model mà cả environment state (random seeds, driver versions, dataset splits tại thời điểm run). Có tooling nào tự snapshot toàn bộ context này không? Hay team đang dùng manual checkpoint + config dump?

Còn khía cạnh "meeting → experiment" — ai đó phải own việc translate research question thành runnable config trong vài phút. Role đó (research engineer?) thường understaffed. Thấy các team khác handle bằng template experiment configs + CLI helper để non-ML folks cũng trigger được baseline run không? (site: labagent .tech)