Author and release a policy in Studio
Turn a written policy into a reviewable rule proposal. Test the rules against explicit facts, record a review of the exact revision, and have another administrator approve it before installation.
Before you begin
You need a provisioned Studio environment with workbook access, the policy-authoring service connection and persistent runtime registry configured. Generation also needs an explicitly configured authoring model. Import, review and deterministic evaluation can run without a model call. These screens are implemented in the source integration; this page does not announce a hosted Studio service or a public model installer.
1. Declare the source and decision#
Open an editable Design Workbook revision and select Policy Studio. Enter the policy's title, source location, usage terms and text. Separate source paragraphs with a blank line. Keep the source precise enough for a reviewer to check each proposed rule.
Under Decision boundaries, name the pack, its purpose, typed inputs, a decision question and its allowed answers. For the support-ticket exercise, ask which queue should review a message and use billing_review, account_support and manual_triage. Declare required inputs explicitly; absence is not the same as a false value.
Select Generate draft, or open Import an existing source-backed proposal to import a JSON object containing source, specification and draft. An unconfigured authoring model produces an explicit failure. It does not silently substitute a parser.
2. Review the proposed rules#
Compare each condition and answer with its cited source paragraph. Check rule order: the first matching rule for a decision selects the answer. Resolve open questions, uncovered source meaning and unclear ontology mappings. A model's fluent explanation is not approval.
Save edits as a new revision. Editing a rule invalidates the displayed test evidence. Save and test again before review.
3. Test outcomes and missing inputs#
| Case to add | What you check |
|---|---|
| Accepted duplicate-charge topic, single request | The policy recommends billing review; it does not approve a refund. |
| Accepted account-access topic, single request | The account-support rule selects its queue. |
| Unaccepted interpretation or multiple requests | Manual triage takes priority over a team route. |
| Required interpretation status omitted | A required-input diagnostic blocks evaluation rather than assuming acceptance. |
Enter expected-answer and blocked cases through the form, using its declared types. For the ticket policy, you supply the interpretation fields explicitly; these tests do not run an English classifier. The release gate replays the saved tests and requires coverage of every decision and rule. Passing these tests checks this reviewed policy against these cases; it does not prove that the prose-to-rule proposal captured every intended business requirement.
4. Freeze a review and obtain separate approval#
In Review and release, add a review note and select Record review of this revision. The immutable bundle binds the source, candidate, explicit cases, workbook identity, ontology digest and executable playbook digest.
A different administrator selects Approve immutable release. Self-approval, stale revisions, changed bundles and unresolved review requirements are rejected. If the workbook changes, review the new revision rather than reusing an earlier approval.
5. Install, evaluate and switch versions#
Select Install in runtime for the approved release. Installation creates an immutable runtime version and makes it active. Under Run the installed policy, enter a decision identifier and structured input facts, then select Run decision. The result identifies the selected version and returns an answer or a blocked result. Your application remains responsible for assigning a ticket or taking any other business action.
To switch back, provide a reason and choose Activate this version on a prior installed version. The service checks the expected active version and target digest. Retrying an old installation does not undo a later rollback. Use Load releases when you want to refresh the displayed state.
Scope of this release workflow#
This is the policy-release slice of a domain pack. The form binds structured-state inputs. A general offline installer combining ontology artifacts, trained weights and governed live-source configuration remains Planned. The persistent file registry serves a single runtime process; distributed activation coordination is also Planned.
Neural interpretation has its own model and calibration gate. Approving a policy release does not qualify an unbound language model. Start with the language-contract tutorial to define that separate task.