Generate or edit decision rules locally in BDL. Convert documents, test against real data, and publish to Sertainly. Evaluate via REST or MCP — deterministic, versioned, traceable.
Open BDL format · Deterministic runtime · No inference at runtime.
# Install the CLI npm i -g @sertainly/cli # Create a package srt init expense_policy # Convert a document into BDL + tests srt convert policy.pdf # Run unit tests srt test # Run real-world cases srt test expenses.csv # Publish to Sertainly srt publish --env production
Every application has rules — approval thresholds, pricing tiers, eligibility checks, routing logic. Right now, those rules are scattered across your services.
Same rule implemented 3 different ways in 3 different services. One gets updated, two don't. Bugs aren't bugs — they're inconsistencies nobody tracks.
Business wants to change a threshold from $5,000 to $10,000. That's a code change, a PR, a deploy, and a QA cycle. For a number.
When a decision is questioned, nobody can prove which version of which rule was in effect. There's no trace, no history, no accountability.
BDL is an open format. Rules can be generated, converted, or edited locally. Test against unit cases or real-world data. Publish to Sertainly's hosted runtime. Evaluate via REST or MCP.
Install the CLI and scaffold a new decision package. BDL is an open, human-readable format — version-controllable and testable without Sertainly.
Run srt convert to turn policy documents into BDL and generate test cases automatically. Use AI-assisted generation, import from external tooling, or edit rules by hand. The CLI supports all three paths.
srt test runs unit tests against your rules and statements.srt test <file> evaluates real-world cases for simulation and verification. Everything runs on your machine — no network calls required.
Run srt publish to push the compiled package to Sertainly's hosted runtime. Pin versions per environment. Roll forward or back instantly. The CLI handles local authoring and testing; Sertainly hosts the runtime, versioning, traces, and audit. Each publish creates an effective-dated release — evaluations route to the version in force on the case's date.
Single POST to /evaluate with your case data. Get back a deterministic status, channel-shaped outputs, and a trace ID. Same input → same output, always. No AI at runtime.
AI can extract rules from documents, generate BDL, and create test cases — but every step can also be done locally with the CLI. AI-assisted compilation is part of your Sertainly plan.
This is what a BDL rule looks like — whether generated from a document, converted via the CLI, or written by hand. Publish it, and get a deterministic decision from the API.
- id: derive_per_person kind: derive phase: derive when: eq: [expense.category, MEAL] set: calc.per_person: expense.amount / expense.attendees_count - id: classify_meal_limit kind: classify phase: evaluate when: lte: [calc.per_person, 75] emit: tag: { tag_set: disposition, value: compliant } reason_code: MEAL_UNDER_LIMIT - id: classify_over_limit kind: classify phase: evaluate when: gt: [calc.per_person, 75] emit: tag: { tag_set: disposition, value: non_compliant } reason_code: MEAL_OVER_LIMIT
// POST /api/public/v1/packages/{slug}/evaluate // expense.amount=185, attendees=3 // 185 / 3 = 61.67 < 75 per person { “status”: “ok”, “case_validity”: { “state”: “valid” }, “execution”: { “state”: “succeeded” }, “outputs”: { “tags”: [“compliant”], “reason_codes”: [“MEAL_UNDER_LIMIT”], “facts”: { “calc.per_person”: 61.67 } }, “trace_id”: “tr_8f2a…c3d1” }
You could. But here's what happens at scale.
| Dimension | Hardcoded Rules | Sertainly |
|---|---|---|
| Change velocity | Code change + PR + deploy + QA | Update rules, publish, instant |
| Consistency | Duplicated across services | Single source of truth |
| Audit trail | grep through git blame | Full trace on every decision |
| Versioning | Implicit (tied to deploy) | Semantic versioning, rollback |
| Ownership | Engineering owns business logic | Business can review and approve |
| Testing | Unit tests for each implementation | Test Bench + CLI test runner |
A decision package is a set of statements. Each statement is a typed rule with a priority, conditions, and deterministic outcomes. Five statement types cover the full range of business logic.
| Statement | Purpose |
|---|---|
derive | Compute facts from case data (e.g. per-person amount, risk score) |
classify | Emit a tag from a tag-set with an optional reason code (e.g. compliant / non_compliant) |
require | Demand fields or evidence before execution proceeds — halts cleanly when absent |
route | Send the case to a named destination for human or downstream review |
select | Pick from a decision table to bind a value into facts |
Every call to /evaluate returns six independent channels plus a derivedstatus. Status is deterministic — same input produces the same output on every call.
Case was valid; execution succeeded. Read outputs.tags, outputs.routes, and outputs.facts for the channel-shaped decision.
A require rule stopped execution because evidence or a field was missing. Response includes outputs.evidence_needed[] — collect and re-evaluate.
Execution failed (engine error, contract violation). Response carries the error inexecution.errors.
The case input failed schema validation. Response carriescase_validity.missing_fields[] and errors[].
Because every evaluation is a pure function of rules + case data, decision packages are fully testable. srt test runs unit tests against individual rules.srt test <file> runs batch evaluation against real-world data for simulation, regression, and CI verification. Same rules, same data, same channels — locally, in CI, and in production.
Not really. BDL is designed for generation, not manual authoring.
Most teams start with a source document — a policy PDF, a compliance spec, a spreadsheet of business rules. Run srt convert and BDL is generated for you, along with test cases. You review the output, run the tests, and publish. If you need to tweak a threshold or add a condition, BDL is readable YAML — but you rarely start from a blank file.
BDL exists so that business logic has a deterministic, testable representation that lives outside your application code. Without it, rules end up in if statements scattered across services, or in LLM prompts where they're neither versioned nor reproducible. BDL gives rules a home: versioned artifacts that can be validated locally, tested in CI, and executed identically in production.
Install the CLI. Convert a document. Test. Publish. Evaluate. No SDK required — if you can curl, you can integrate.
Once your workspace is provisioned, install the CLI and authenticate.
Scaffold a package. Convert a source document into BDL — rules and tests are generated together.
Run unit tests against rules, or evaluate real-world cases for simulation.
Push to Sertainly. Call the API. Get a deterministic decision.
CLI-first decision infrastructure. Author and test locally in open BDL; the governed runtime handles versioning, traces, and audit.