Domain packs
Give your team a consistent next step: which queue should review a support ticket, or who should review a purchase? A domain pack connects the written policy, the facts it needs and the decisions your application can use.
Start with a business problem#
Classify what the customer is asking
English in, a category out: fulfillment, expedite or unsupported. Follow actual model scores through the separate confidence gate.
Authoring exerciseRoute a support ticket to the right team
Use the message and routing policy to recommend billing review, account support or manual triage.
Purchasing and policy ownersKnow which purchases need review
Route supplier and manager review, then see what changes when the approval threshold moves.
The support-ticket exercise supplies a policy and expected cases for authoring; its hosted and local demo is Planned. The classification walkthrough shows recorded model predictions. The existing policy fixtures include written sources, downloadable Studio drafts and recorded outcomes over supplied facts.
What your team can review#
The policy owner checks a proposed rule against its source clause. The operations team supplies examples that should pass, stop or request more information. A separate administrator approves the exact tested revision. The application then uses that installed version, while retaining control of permissions and business actions.
Availability
The domain-pack integration and Studio policy-release workflow are implemented in the source distribution. They are not included as a new public API in the published Decision Runtime package. A general offline installer and a publicly distributed trained checkpoint are Planned. The evaluated language model remains unbound because it did not qualify for admission. See the measured result.
Pack, playbook and model#
| Artifact | Responsibility |
|---|---|
| Domain pack | Declares the components that belong together: ontology, playbooks, knowledge artifacts, interpreter configuration and decision interface. |
| Ontology | Names concepts, aliases, properties, value types and units. It supplies vocabulary to the language contract. |
| Playbook | Defines the questions the runtime can answer, required evidence, allowed answers and policy rules. |
| Language contract | Projects the ontology and playbook into a bounded interpretation task, with explicit unsupported requests. |
| Model and calibration artifact | Proposes a finite choice under that exact contract. Its identity, resources and confidence policy are checked before admission. |
A playbook is part of a domain pack. A trained model is an optional input interpreter. The existing sealed runtime pack is an executable artifact with its own format and loading rules; it is not an interchangeable name for every artifact in this larger domain definition.
Two useful workflows#
Turn policy prose into reviewed rules
Propose rules from a source, inspect citations, test outcomes, review an immutable revision and install an approved version.
Runtime interpretationMap a request to a supported assessment
Use neural vectors and finite option scores to select which declared question the runtime should evaluate.
Authoring can use a configured language model to draft policy. Native runtime interpretation uses an encoder and finite prediction head. These are separate model roles with separate evaluation requirements.
Keep interpretation and authority separate#
- Select the record in your application.
The first supply-chain contract assumes the application has already selected an order.
- Interpret the request.
The native model proposes a supported assessment or an unsupported result. It does not generate executable policy or invent missing facts.
- Check compatibility and admission.
Validate the candidate, model identity, language contract and calibration policy. An incompatible artifact or unqualified threshold blocks execution.
- Resolve evidence and evaluate.
The shared runtime applies the declared policy to validated inputs and returns an answer or a diagnostic. Your application retains control of permissions and business actions.
Start with a bounded language contract, then inspect the published evaluation. For measured interchangeability, read the provider regression.