Prepare a bounded language contract

Define exactly what an English request may ask your application to assess. Keep the meanings in your ontology and playbook, and make unsupported requests explicit before training a model.

This walkthrough prepares a domain specification. It does not train or execute a model. For a runnable exercise with the recorded data, continue to Audit a native-model evaluation.

1. Select a record before interpreting language#

Let the application identify the order. The model receives that selection, the English request, domain vocabulary, a bounded question and allowed answers. This removes record selection from the model's task and lets you measure one capability at a time.

{
  "state": {
    "request": "Can this order go out from stock?",
    "selected_records": {"order": "application-selected-record"}
  },
  "question": "Select the single current assessment requested.",
  "allowed_answers": {
    "fulfillment": "Assess whether the selected order can ship from stock.",
    "expedite": "Assess whether the selected order needs expedited delivery.",
    "unsupported": "Not a single supported current assessment."
  }
}

The recorded runtime also supplies the ontology-derived vocabulary and binds the full request to its language contract. The shortened example above is for reviewing the task boundary, not a replacement for the generated contract.

2. Put language in the ontology#

The language projection carries concept names, aliases, definitions, types and units from the ontology. Decision descriptions and required evidence come from the playbook. Avoid maintaining a second, unrelated keyword dictionary. A changed meaning or answer set needs a newly hashed contract and compatible calibration.

3. Write contrasts that change the label#

These are newly written teaching examples, not additional benchmark measurements. Keep related paraphrases and contrast pairs in one data partition. Separate business settings across training, development, calibration and test. Review negation, historical tense, action commands, ambiguity and multi-request language explicitly.

4. Keep interpretation labels separate from policy answers#

fulfillment names the assessment to run. It is not a release answer. Once interpretation is admitted, resolve the playbook's required evidence and let the policy determine the answer. A missing quality-hold observation must not become false.

Use Studio to review the policy and its required-input cases. Evaluate language selection separately using candidate accuracy, unsupported-request errors, admitted precision and useful coverage.

5. Prepare a compatible development environment#

For source integration, obtain the matching domain-pack sources and their pinned dependencies through your Helixor access arrangement. The verified local setup uses Python 3.12, an isolated environment, the pinned model snapshot and a separate calibrated-checkpoint cache. Training and inference need model resources that are not included in this public documentation.

The verified source setup exercised macOS arm64. Linux and accelerator training require their own environment validation. Reserve storage for base resources, checkpoints and bound copies; the measured model has 421,293,827 parameters; 1,685,197,088 bytes of float32 weights. Runtime inference uses the already populated cache and fails explicitly when a required resource is absent.

Recorded 2026-10-03 on M5 Max, macOS arm64, Python 3.12.12, 4 CPU threads, batch size 1. Synthetic labels. Provider inference, tokenization and candidate validation; excludes first call, live evidence retrieval, reasoning and business action execution. Evidence and reproduction limits.

A provider change needs its own compatible artifact and calibration. Do not transfer another provider's threshold. Do not bind the recorded checkpoint: its calibration gate did not qualify.