Organetic emblem Organetic Verification layer for AI reasoning
Menu

Docs / Install

Install and usage for the released validator line

This page is the operational guide after quickstart: bundle layout, path assumptions, command usage, and the narrow expectations that come with the current Stage 1 surface.

The examples below assume the current Windows bundle layout and PowerShell usage. Keep the extracted directory intact for the first pass.

Back to quickstart Move into GitHub Actions

Install flow

Use the release bundle as the primary operator surface

  1. Download the current release archive and sidecar checksum Start from the approved release bundle for the current shipped cut.
  2. Verify the archive checksum before extracting Do not trust the bundle until the checksum sidecar matches.
  3. Extract the archive without rearranging its contents Keep tobi.exe, examples/sample.tsubasa, and examples/golden/fixtures.json together.
  4. Run the CLI from the extracted directory Use .\tobi.exe --help first, then the shipped sample and shipped fixtures.

Bundle assumptions

  • tobi.exe
  • examples/sample.tsubasa
  • examples/golden/fixtures.json
  • SHA256SUMS.txt

Operator expectation

Optional PATH setup can come later. For first use, it is better to run the shipped executable directly from the extracted directory.

PowerShell

Release-accurate command usage

.\tobi.exe --help

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

.\tobi.exe golden .\examples\golden\fixtures.json
OK (45 fixtures)

Path assumptions

Keep file paths explicit

  • use the shipped sample path for the first canon run
  • use the shipped fixtures path for the first golden run
  • only switch to project-owned paths after the shipped bundle succeeds locally
  • treat missing files as operator/setup issues before treating them as validator issues

Canonical ASCII

Stable visible output

Equivalent accepted source skins should converge into stable canonical ASCII that is practical to diff, review, and compare.

Hash output

Compatibility-oriented receipt

HASH: is the current user-visible _h surface for the accepted canonical artifact, not a broader platform identity layer.

Diagnostics

Deterministic rejects

Rejected input should surface stable diagnostic codes and spans under the current validator contract rather than silent acceptance.

What this guide supports

Install, canonicalization, diagnostics, conformance checks, and first operator success on the released validator line.

What this guide does not imply

No runtime execution, no backend output, no verification API, and no broad SDK or platform maturity claim.

Where to go next

Move to GitHub workflow fit, diagnostics, or support after the local bundle path is stable and reproducible.

After install

Use the local bundle path first, then decide whether workflow fit matters

Once install and first local runs are stable, the next useful move is narrow: evaluate diagnostics, decide whether a GitHub gate is helpful, and route any reproducible friction into support or deferred evaluation details.

GitHub Actions starter Diagnostics reference Support and issue reporting