Released Stage 1 product line

The verification layer for AI reasoning

Organetic helps move reasoning from trace-like and opaque toward canonical, reproducible, validator-checkable artifacts.

Its first released product, AI Verification Engine / Tobi Validator, is a narrow validator-first CLI surface for deterministic reasoning verification.

Validator-first reasoning infrastructure Trust layer for canonical reasoning artifacts

View documentation Explore Tobi Validator GitHub workflow fit View public GitHub repo Request evaluation access

Current shipped contour Installable validator CLI

Compatibility identity Canonical ASCII and _h

Current launch path Docs, public repo, and GitHub workflow fit

The problem

Modern reasoning workflows still lack a trust layer

AI systems can generate answers, plans, and workflow steps, but that still does not prove whether the reasoning artifact is canonical, reproducible, or validator-backed across environments.

Traces are not enough

Trace-like artifacts are hard to compare

A trace can be observable and still remain unstable, verbose, or difficult to compare across runs and environments.

Evaluation is not verification

Performance signals do not establish canonical form

Evaluation says a system seems to perform well. Verification checks whether the reasoning artifact is canonical, reproducible, and validator-backed.

Workflow risk

Reasoning discipline matters in gated pipelines

This becomes acute in agent workflows and reproducibility-sensitive scientific workflows where unstable artifacts create downstream risk.

First released product

Tobi Validator is the first released Organetic product

Stage 1 is a narrow released validator line: installable CLI, deterministic diagnostics, canonical ASCII output, compatibility identity, and conformance / golden execution.

installable validator CLI
canonical ASCII output
_h compatibility identity output
deterministic diagnostics
conformance and golden execution
thin packaging and install / usage framing

Not implied

This does not claim broad platform maturity, runtime/backend maturity, a shipped verification API, or a complete scientific operating environment.

Representative Stage 1 CLI output

$ tobi canon examples/sample.tsubasa
CANON:
atomic{ let x = 1 in x }
HASH:
7f13d4e2

$ tobi golden examples/golden/fixtures.json
OK (45 fixtures)

See a real gate in action

From reasoning artifact to CI pass/fail

Tobi Validator is most useful when a reasoning artifact becomes a workflow gate: an agent or team produces an artifact, Tobi validates it, the workflow stores canonical output and diagnostics, and CI decides whether the change can continue.

artifact enters the workflow
Tobi emits canonical ASCII and _h
deterministic diagnostics explain pass/fail behavior
GitHub Actions can block merge on validator failure

Open GitHub workflow guide Request evaluation access

Workflow gate pattern

agent output
→ reasoning artifact
→ tobi canon / tobi golden
→ canonical ASCII + _h + diagnostics
→ pass / fail CI gate

Why this matters

Validator-backed reasoning is about boundary and convergence

A useful validator does more than reject broken input. It also collapses equivalent valid forms into one stable canonical result. That is what turns a workflow artifact into something reproducible and comparable.

Boundary

Malformed and noisy artifacts should fail cleanly

The validator should reject malformed siblings and visually confusable input instead of letting unstable artifacts pass deeper into a workflow.

Convergence

Equivalent valid forms should converge

Different valid spellings of the same meaning should converge to one canonical output class instead of creating false differences in review, CI, or agent handoff.

Operational value

Stable artifacts are easier to gate and reuse

When an artifact becomes canonical and validator-checkable, it becomes more useful as a gate surface before merge, release, or expensive compute.

Read: Finding your first reasoning artifacts Read: Tsubasa for agents Read the Tsubasa Stage 1 reference

How it works

A compact view of the validator-backed stack

For launch readers, the useful point is simple: noisy inputs stay in the Data Plane until the Bridge makes the noisy-to-exact transition explicit. Canonical reasoning artifacts live in the Control Plane under validator discipline.

Data Plane

Noisy, measured, trace-like inputs

Experiments, measurements, simulations, statistics, and probabilistic or ML outputs live here. They are non-canonical by default.

Bridge

Explicit noisy-to-exact boundary

Normalization and discipline happen here. It prevents hidden float-to-decision or noisy-to-canonical jumps and makes the transition into exact reasoning explicit.

Control Plane

Canonical reasoning artifacts

This is the exact semantic control surface: deterministic evaluation structure, decision and proof discipline, and validator-checkable effects.

Tsubasa Canonical reasoning language and semantic layer.

Liu Sugar and authoring layer only.

Tobi Reference validator, diagnostics surface, and trust anchor.

This homepage keeps the short launch view. The full plane/component split and canonical pipeline remain on the architecture page.

See the full architecture

Integrations

GitHub-first today, with limited adjacent workflow contexts

The current public launch motion is GitHub-first: the public OrganeticSphere/tobi-validator repository carries the customer-facing docs, examples, and action-wrapper entry path, while uses: OrganeticSphere/tobi-validator@v1 provides the narrow workflow gate. The current public evaluation path runs through TOBI_EVAL_TOKEN, so this is a repo and wrapper path, not unrestricted public binary delivery.

GitHub Actions

Current public workflow path

Start in the public OrganeticSphere/tobi-validator repo, then run uses: OrganeticSphere/tobi-validator@v1 for canon and golden checks with TOBI_EVAL_TOKEN configured in the workflow repository.

GitHub-first

GitLab CI

Adjacent CI context

Comparable validator stages can be discussed later for teams evaluating adjacent CI surfaces.

Secondary context

Nextflow

Scientific workflow fit

Use this as a workflow-fit discussion surface for reproducibility-sensitive pipelines.

Evaluation context

Snakemake

Rule-level workflow context

Discuss validator-backed acceptance and mismatch detection in rule-driven pipelines as a later fit path.

Evaluation context

Databricks / MLflow

Secondary discussion layer

Consider tracked validation steps here only as a secondary workflow-fit context.

Secondary context

Organetic

Where AI reasoning becomes trustworthy

Organetic is shipping its first public surface as AI Verification Engine / Tobi Validator. The homepage stays centered on the released validator line, while deeper project context stays on the About page.

Biology remains a deep domain and long-term application zone, but the current public launch stays focused on reasoning verification through a narrow CLI surface.

Read about the project

Workflow fit

Talk to Organetic about GitHub workflow fit and CI integration

The public path is documentation-first and GitHub-first. If you need help deciding where Tobi Validator should sit in your CI or validator gate, use that narrow path first, then contact Organetic for workflow-fit questions.

Get 7-day evaluation access View documentation Explore Tobi Validator