OmniLAB documentation#
Repository home · Documentation website · Release and upgrade guides
OmniLAB helps Codex delegate bounded work to local models while keeping planning, review and final acceptance with Codex. Start with advisory work; add the restricted OpenHands implementation lane only after its separate qualification gates pass.
Development documentation — 0.5.0.dev0. This website describes the development branch. It does not turn that candidate into a qualified release or upgrade an installed controller. The released v0.4.1, development source, installed package, active configuration and dated live evidence are distinct states.
Start here#
| Your question | Canonical guide |
|---|---|
| What does OmniLAB do? | Overview |
| How do I try a bounded advisory task? | Quickstart |
| What do the controls and job states mean? | User guide |
| How do the three task lanes and two inference providers relate? | Workflow and source-linked diagrams |
| How do I open the independent applications or manage Docker safely? | Standalone access and Docker |
| What remains experimental for Strata? | Inference qualification roadmap |
| Can Strata operate independently today? | Standalone status, blockers and acceptance |
| How will OpenHands use Strata safely? | Separate implementation qualification |
| Why is Janas separate? | Independent supervisory-agent research |
Implementation and evidence#
| Area | Read next |
|---|---|
| Python decisions, contracts and verification | Workflow source map, selective execution |
| Settings and installation | Configuration reference, selective setup |
| Retained advisory and durable workflows | Architecture, workflows, companion workflows |
| Tested scope and unresolved gates | Implementation report, OpenHands qualification, human acceptance ledger |
| Recovery, security and operations | Recovery, troubleshooting, security |
| Measurement and release | Comparison protocol, release readiness, development snapshot |
| Historical benchmarks and contributed work | Benchmark index, local contribution ledger, adaptive delegation |
| Upgrades and historical release evidence | Release and migration index, changelog |
| Contributor reference | Contributing, project policy, profiles, decisions, dependencies |
Reading status correctly#
Tested means a named test or dated live record supports that exact scope. Synthetic tests do not establish live model quality. Experimental means code exists but production admission is not established. Planned means a future qualification target, with no automatic enabling, download or startup.
Acceptance reports use VERIFIED, FAILED, BLOCKED or NOT TESTED for each individual requirement. VERIFIED inventory or automated tests do not imply VERIFIED live operation. BLOCKED identifies an unmet prerequisite; NOT TESTED identifies an observation that has not been performed. Keep those scopes visible.
Historical release reports are grouped under releases; their findings remain intact and the website retains the previous page URLs. Use this index and the current workflow for navigation; do not treat an older successful probe as current permission to run another model or lane.