Everything here is a declaration.
You declare the policy, and you declare everything around it the same way: the screens a reviewer works in, the entities the engine reasons about, the roles, the queues, the actions, and the fields that count as sensitive.
Built into the Swiftward service you run.
What you declare
| Declared | What it covers |
|---|---|
| Rules and signals | conditions, effects, constants, the state a rule keeps, and the functions it calls |
| Entities | what the engine reasons about, their fields and their statuses |
| Screens | what an operator or a reviewer works in, their columns, filters and routes |
| Actions | what a rule may do, and who is allowed to invoke each one |
| Parameters | the settings an operator changes per tenant, without redeploying Swiftward |
| Tamper-evidence | which tables are tamper-evident, and from which moment a row is covered |
| Audit behavior | what is recorded, at what depth, and what a message says when something is refused |
hitl_cases_list:
entity: hitl_case
route: /hitl/cases
columns: [created_at, queue, entity_id, event_type, status, priority, case_type,
assigned_to, decision, case_id] That is the review queue an operator opens, written like a rule. Adding a column, changing the route or splitting one queue into two is a change to a declaration.
The claims this makes true
| The claim | Why it holds |
|---|---|
| A review queue shaped to your team | the queue and its screens are declared |
| Your use case running in weeks | nothing is built for it; it is declared |
| A control your auditor asks for is usually configuration | the control and its evidence are both declarations |
| Adapting the platform to your integration is configuration | you are changing a declaration rather than forking the product |
It is also why so little here is fixed behavior. What a queue does when nobody works it, what a gateway does when the engine is unreachable, what happens to an event no rule matched: each is yours to declare. A vendor who hard-wires them has decided something about your operation without asking.
The look is declared too
| Declared | What it covers |
|---|---|
| Colors and fonts | light and dark are declared separately, so you set each one |
| Typography and density | heading sizes and line heights, row density, corner radius, zebra striping on tables |
| What is shown at all | top bar, side rail, sidebar, tabs, breadcrumbs, tenant switcher — and per screen type, the title, the action buttons, the row count |
| Your own stylesheet | for anything the fields do not reach. It loads after the theme values, so your rules win without !important |
Each field is named after the CSS variable it sets — surface_2 sets --surface-2 — so your own stylesheet uses the same names. Lighter and darker shades of your accent color are generated for you, and you can set any of them by hand.
Every setting applies per tenant and per user. Two tenants on one deployment look like two products. A screen embedded in your product through an iframe declares its own frame, so it is not the full application with parts hidden.
What stays the same in every deployment
The engine, the gateways and the order the rules run in are ours, and the same for every customer. That way determinism, ordering and the record work the same in every deployment.