What Stage 1 includes
Current released contour
- installable validator CLI
- canonical ASCII output
_hcompatibility identity output- deterministic diagnostics
- conformance and golden execution
- thin packaging and install / usage framing
AI Verification Engine / Tobi Validator
A validator-first CLI for canonical reasoning verification
Tobi Validator is the first released Organetic product. It is designed to canonicalize, identify, and validate reasoning artifacts in a deterministic workflow-friendly way.
What Stage 1 does not include
Still intentionally narrow
- not a mature runtime or backend platform
- not a broad orchestration suite
- not a shipped verification API surface
- not the complete Organetic platform
Who should evaluate this now
Tobi Validator fits teams that need a narrow workflow gate
Stage 1 is most useful when a team already has artifacts that should be accepted, rejected, canonicalized, or compared before merge, release, tool action, or expensive downstream computation.
AI / agent teams
Gate agent-produced reasoning artifacts
Use Tobi before an agent output becomes a tool action, configuration change, merge candidate, or preserved reasoning artifact.
Developer tools / CI
Validate before merge
Add a validator-backed gate to GitHub Actions and treat deterministic diagnostics as part of review evidence.
Scientific workflows
Protect reproducibility-sensitive steps
Use a narrow validator step before downstream computation where unstable artifacts would create expensive or hard-to-debug failures.
Evaluation teams
Separate evaluation from verification
Keep scores and traces, but add a separate artifact validation boundary for
canonical output, _h, diagnostics, and conformance behavior.
Reasoning artifacts
What Tobi is trying to stabilize
A reasoning artifact is not just any smart-looking output. It needs to be explicit, reviewable, repeatable, and meaningful enough to accept, reject, or compare inside a workflow gate.
Tobi matters when a team wants artifacts to become more canonical, reproducible, and validator-checkable instead of remaining trace-like and hard to compare.
Canonical convergence
Equivalent valid forms should not create false drift
A useful validator does more than reject broken input. It also collapses equivalent valid forms into one stable canonical result instead of preserving spelling-level noise as a fake semantic difference.
This is one of the practical reasons to use Tobi in CI and multi-agent handoff: equivalent accepted forms should remain stable, and malformed nearby siblings should fail cleanly.
Public GitHub path
Public repo for docs, examples, and the action wrapper
The public repository at OrganeticSphere/tobi-validator is the customer-facing
surface for the released validator line. It carries the docs, examples, workflow
guidance, and the GitHub Action wrapper used as
uses: OrganeticSphere/tobi-validator@v1.
Real execution remains controlled and separate from the public repo. The current public evaluation path
uses the repository secret TOBI_EVAL_TOKEN, so the public path is repo
plus wrapper guidance, not unrestricted public full-binary download.
Inputs and outputs
What the validator produces
Tobi Validator takes reasoning artifacts into a canonical path and produces stable outputs that can be compared, gated, and tracked in workflows.
Canonical ASCII
Stable human-readable output for comparison and review.
Compatibility identity
_h output for compatibility-oriented identification.
Deterministic diagnostics
Consistent pass, fail, and mismatch reporting.
Representative CLI surface
$ tobi canon sample.tsubasa
atomic{ let x = 1 in x }
_h: 7f13d4e2
$ tobi golden fixtures.json
PASS fixtures/accept/basic.tsubasa
PASS fixtures/reject/hash_mismatch.tsubasa
summary: 2 passed, 0 failedWorkflow fit
Where it belongs
Tobi Validator is designed to sit as a gate step in CI and workflow systems, where deterministic artifact checking matters more than trace collection alone.
- GitHub Actions pull request gates as the current public workflow path
- adjacent CI and scientific workflow-fit discussions after the docs-first path is clear
- tracked validation steps as a narrow secondary context, not a broader platform claim
Agent authoring discipline
What agents should not invent
In the current Stage 1 corridor, agents should not invent regex runtimes, generic byte-scanner semantics, pseudo-language wrappers, or backend/API behavior and then call those things “Tsubasa”.
The safe approach is narrower: small explicit accepted cases, nearby rejected siblings, and canon/golden-oriented case sets.
Integrations
GitHub-first public workflow path
GitHub Actions
Current public path: start from the OrganeticSphere/tobi-validator repo,
then use OrganeticSphere/tobi-validator@v1 as the narrow workflow wrapper.
GitLab CI
Adjacent CI context for later workflow-fit conversations, not the primary launch path.
Secondary contextNextflow
Scientific workflow-fit context for reproducibility-sensitive evaluation.
Evaluation contextSnakemake
Rule-level validator fit discussion rather than a current public launch surface.
Evaluation contextDatabricks / MLflow
Secondary workflow context for teams already using managed tooling.
Secondary contextWorkflow fit
Use the docs-first path before broader evaluation
The current public path is narrow: understand the product, use the released docs, and review GitHub workflow fit. Guided evaluation remains deferred and secondary.