STROT: compile a narrow decision task into a reusable artifact

Define the decision before compiling

The author describes compiling intent and a typed output schema, then calling the resulting artifact repeatedly. This suits a stable set of choices. The claimed speed is a project measurement and should be checked with your own input sizes and hardware.

STROT repository ↗

Abstention depends on the examples

The developer notes describe held-out calibration and coverage guarantees with distribution assumptions. Those guarantees do not imply that every dispatched answer is correct. New request types or a changed input distribution can invalidate the calibration. Compilation also executes generated code; lint checks do not provide a sandbox.

STROT developer notes ↗

A small evaluation you can design

For a fictional help desk, label “duplicate invoice” as billing, “reset my password” as account access, and an unrelated poem as outside scope. Keep a separate test set with ambiguous and unseen cases. Count both wrong routes and inappropriate answers instead of scoring only requests the system accepts.

STROT developer notes ↗

What you can do

1. Read the developer notes and write a labelled, held-out test set for one narrow routing job. Include ambiguous inputs and explicit cases that should remain undecided. Open reference ↗

Where the evidence stops

This is a source-checked design explanation. Artifact compilation, runtime performance and calibration behavior have not been independently executed.

Sources read. Sources checked October 19, 2026. No product was installed, model run or complete external workflow executed.

Sources & further reading