Quickstart

Start with a decision in your browser. Then explore the examples on your machine, change an example with your Developer license, and use the same repository's artifacts to create a pack in Studio.

1. Try the hosted samples — no setup or signup.
2. Clone and explore locally — Git and Python, no signup.
3. Get a license and customize an example.
4. Create your own pack in Studio.

1. Try the hosted samples#

Open the hosted playground. You do not need an account, a license or an installation. Start with the data-protection guard to learn how to read a decision.

1. Choose the data-protection pack.

   Enter the synthetic text Employee onboarding: SSN is 123-45-6789. and select Evaluate.

2. Read the result.

   The action block_glba_ssn_leakage tells your application to stop the payload. The triggered rule explains why. The remedy redacts the sensitive value; a block action still means you must not forward it. The receipt is a fingerprint you can use to check the decision later.

3. Change the input.

   Try Employee onboarding is complete. and evaluate again. With no sensitive value to match, the expected action is permit_clean_payload. Compare the action and triggered rules.

Next, choose an available mortgage or commercial-credit sample to see decisions over structured facts. The pack picker shows which samples are available. You can also explore the sales assistant and search and games. Use synthetic data in these public samples.

2. Clone and explore locally#

Clone the public helixor-decision-demos repository. Use Git and Python 3.11 or 3.12; the walkthroughs below need no signup, license, extra packages or server.

git clone https://github.com/HelixorAI/helixor-decision-demos
cd helixor-decision-demos
python3 classification/review.py

Follow how each recorded request was assigned to a category, which cases were misclassified, and whether the interpretation passed admission. These records use order questions; the support-ticket exercise later in this guide defines a new classification task.

Explore the other cases and check the example files:

python3 domain_packs/review.py
python3 domain_packs/review.py --check

The classification walkthrough shows how order questions were assigned to fulfillment, expedite or unsupported. Compare the scores with the expected category and the admission result.

Keep this clone for the next two steps. The playbooks/ directory contains editable runtime examples; domain_packs/ contains policy drafts and cases for Studio. See the repository tour for the full map.

3. Get a license and customize an example#

When you are ready to compile your own rules, request a Developer license. Include your name, work email, organization and the decision you want to build. Requests are reviewed manually; follow Request access for delivery of your license and runtime wheels.

Install the runtime, save your issued license as ~/.helixor/helixor.hxlic, and check that it includes custom_playbook_compilation:

chmod 600 ~/.helixor/helixor.hxlic
helixor-pack inspect-license
python examples/11_compiled_pack.py

Example 11 compiles and runs the supplied playbooks. Start your change from a copy of the internal-identifier example:

cp playbooks/internal_ids.yaml playbooks/my_internal_ids.yaml

In playbooks/my_internal_ids.yaml, change pack_id to custom.my_internal_ids.v1. Keep the rule IDs and actions; change the ticket_id pattern from \bTCK-\d{6}\b to \bCASE-\d{6}\b. This makes the example redact your new ticket prefix.

helixor-pack compile --playbook playbooks/my_internal_ids.yaml \
  --license ~/.helixor/helixor.hxlic --out my_internal_ids.hxpack
helixor-pack run --pack my_internal_ids.hxpack \
  --license ~/.helixor/helixor.hxlic --text "See CASE-004211 for the fix."
helixor-pack run --pack my_internal_ids.hxpack \
  --license ~/.helixor/helixor.hxlic --text "See TCK-004211 for the fix."

The first input should return redact_ticket_id and replace the identifier with [REDACTED_TICKET_ID]. The second should return permit_clean_payload. You changed a rule in a versioned pack; the calling code stays the same. Continue with Add custom rules and Testing policies.

4. Create your own pack in Studio#

Design a support-ticket routing pack: a reported duplicate charge goes to billing review, a sign-in issue to account support, and ambiguous or multiple requests to manual triage. The message supplies the evidence; the result recommends who should review it.

You need a provisioned Studio environment with policy authoring and runtime installation enabled. Draft generation also needs a configured authoring model. Ask your Helixor contact for its URL and access; a Developer license alone does not provision Studio.

Keep the clone open as a format reference: domain_packs/purchase-review.json illustrates the source, specification and draft sections, and domain_packs/cases.json shows inputs and expected answers. Those are existing policy fixtures, not support-ticket results.

1. Declare your routing policy.

   Open an editable Design Workbook revision, select Policy Studio, and enter the support-routing source policy. Under Decision boundaries, name your pack and decision, declare the topic, interpretation-acceptance and single-request inputs, and list the three allowed queues.

2. Review a draft.

   Select Generate draft with your configured authoring model. Compare each proposed rule with the policy source. Manual triage takes priority over a team route when the interpretation is unaccepted or the message has multiple requests. Save your edits as a new revision.

3. Test and customize.

   Enter the expected cases through the typed form, including missing inputs and manual triage. Supply the interpretation fields yourself for these policy tests; this does not classify English. Then add a cancellation-to-retention rule, update the allowed queues and source policy, and test that change before review.

4. Review and approve.

   Run the tests for every decision and rule. Select Record review of this revision, then have a different administrator select Approve immutable release. If you edit the policy again, save and test the new revision before review.

5. Install and run.

   Select Install in runtime. Under Run the installed policy, enter the decision identifier and structured facts, then select Run decision. Check the installed version, answer and rule behind the result.

After approval and installation, you have a reviewed routing policy in Studio. Follow Author and release a policy in Studio for version changes and rollback. Testing a language interpreter is a separate step from testing these policy rules. A runnable hosted/local support-ticket classifier is Planned. The YAML playbook compiled in step 3 uses a separate runtime format.