Decision-model families and evidence

This page is a navigation map, not a leaderboard or live census. Start with the decision you need to make, then choose a model family whose output has the right meaning. Treat provider and project claims as evidence to test in your own workflow.

Start here

Augustus skill — the concise runtime method.
Judgment class — family selection and placement.
Validation — held-out workflow evaluation.
Boundary audit — ownership, authority, and safety boundaries.

Default hosted exemplar

Augustus uses TypeSafe Jev Choice/Score/Noul as its default hosted exemplar. That is a practical teaching preference, not a claim of universal superiority, equivalence with other families, or market adoption. Read the current TypeSafe skills before writing integration code, and verify contracts against the service version you use.

Family map

Scroll to compare all columns →

Family	Useful for	Evidence and boundary to inspect
Hosted decision API	Bounded choices, ordinal scores, or compact classifications over caller-supplied evidence	Current request and response contract, latency, privacy, candidate coverage, and held-out task quality
Supervised classifier or decision head	Repeated decisions with labeled domain data and controlled deployment	Dataset provenance, class balance, distribution shift, calibration where policy needs it, and serving behavior
Encoder or extractor	Locating spans, entities, fields, or schema-conditioned signals	Offset fidelity, recall on target documents, multilingual or domain coverage, and the downstream decision that consumes the extraction
Ranker or reranker	Ordering retrieved items, search results, reviews, or work queues	Candidate recall before ranking, order metrics tied to user outcomes, tie behavior, and fallback when evidence is weak
Constrained autoregressive readout	Selecting among allowed values using an existing generative model	Tokenization and option-order effects, latency, output constraints, and whether scores have the semantics required by policy
Vision or perception scorer	Judging images, regions, controls, or visual state	Sensor coverage, localization error, modality loss, adverse visual cases, and independent checks before action

These families can be composed. A common pattern extracts observable evidence, ranks or classifies it, applies explicit policy, then lets deterministic code or an authorized person perform and verify the action.

How to choose

Write the desired behavior and a simple deterministic or human baseline.
Separate exact computation and hard constraints from the uncertain judgment.
Define the output semantics: category, order, score, abstention, or evidence span.
Check that the candidate set and observations contain the information needed for the decision.
Set policy from action costs and authority, including fallback and review.
Evaluate held-out workflow cases and inspect errors before expanding scope.

Evidence labels

Contract — behavior guaranteed by a current specification or API contract.
Reported — a result stated by its author or provider and not independently reproduced here.
Reproduced — rerun with enough procedure and artifacts to inspect.
Hypothesis — a plausible design claim awaiting a discriminating test.
Unknown — evidence is absent, stale, or insufficient for the decision.

Keep the label attached when a claim is copied into a design note. A public benchmark can support a hypothesis, but deployment policy should follow evidence from the intended inputs, failure modes, and action costs.

Research and provenance

The public runtime skill stays concise. Broader observations and historical snapshots remain available for research and audit:

Current and past release notes are on GitHub releases. For corrections or new evidence, use the repository’s contribution guide.