Check

POST /v1/check is the product. It takes the facts of one transaction, or of one action you are about to take, checks them against the law's rule set and your company's policies for the same domain — or against your policies alone, where we hold no law for your country — and returns one of four answers. Every check is stored before its answer is sent, and its check_id gives the same answer back for the whole retention period.

The request

{
  "rule_set": "de_gifts_entertainment",
  "transaction": {
    "ref": "INV-2025-0142",
    "channel": "card",
    "status": "executed",
    "actor": { "kind": "agent", "id": "agt_expenses", "on_behalf_of": "emp_4f1c" },
    "provenance": { "request_ref": "REQ-88121", "approval_ref": "APR-2025-311" },
    "run": "TRIP-4471",
    "system": "expenses"
  },
  "facts": {
    "booking_date": "2025-11-20",
    "account": "4630",
    "amount_gross": { "amount": 2975, "currency": "EUR" },
    "recipient": { "name": "Dr. Anna Müller", "org": "Müller GmbH", "customer_number": "10442" }
  }
}

Facts, never conclusions

A fact is something that can be observed: a date, an amount, an account, a code, who received it, whether the receipt names the guests. A rule never asks you for a conclusion — "deductible", "appropriate", "a business trip" — because deciding those is what the rules are for.

This binds an agent most of all. An agent sends what it is about to do and where the instruction came from — the amount, the merchant, the date, the request it is working on — and never its own judgement that a trip is business or that an amount is reasonable. Purpose is a conclusion; provenance is a fact.

Where a rule set takes a person as a fact — who approved the action, approved_by — your own software sends somebody in your account, by their Himmel id, as a signer in your settings is. An id nobody in your account has is refused with 422 invalid-fact, code unknown_user, before anything is stored, and the refusal never repeats it.

A number is zero or more: an amount, each figure beside it, a whole number. One sent below zero is refused with 422 invalid-fact, code below_zero, naming the fact, unless the rule set declares that fact signed, which the catalogue shows. An action taken back is reported, never sent as its negative. A code a fact carries, a string or an account, is at most 200 characters.

Some facts only you can know, and they are checked as you send them, kept with the key that sent them: an approval your software holds, your own figure for an amount in another currency, a customer's number — and so who the customer is. A name, a number or an address never sent before, or an id no answer gave, is a customer with no history yet. The check log shows who sent what.

An agent never names a person

A key made for an agent never sends a person — a fact of type user, such as approved_by — nor the figure your rule set marks as what an approval was given for: Himmel holds them for the agent, and an agent's word is never taken as someone's approval. Sent with a value, one is refused with 422 invalid-fact, code not_the_keys, naming the fact and never its value, before anyone is looked up — so the refusal says nothing of who is in your account — and nothing is stored. Left out, or sent as null, it is read as Himmel holds it and kept so: none, where nothing is recorded on the action. So an answer that needs an approval names who gives it, rather than asking the agent for approved_by; and where one of your people decides a question on the action and it goes on, their decision still stands as their approval (Resolutions). A completion or a correction from the agent's key carries what its action recorded: an approval your software sent with it stands, and a null the agent sends leaves it standing. What an agent reads before it starts names these facts as never sent, and the MCP server's check tool does not offer them.

Your own software, with your account's own keys, and your people signed in send approved_by as before, on their word.

An amount in another currency

Every rule set says the currency its limits are in, and the catalogue lists it as currency. An amount is { "amount": <minor units>, "currency": "<ISO 4217 code>" }. One in another currency than its rule set's is sent with what your own systems record it as in the rule set's currency — your payment processor's settlement amount, your shop's amount in its own currency, the card statement, your ledger — under equivalents, a figure per other currency:

"amount": { "amount": 3500, "currency": "CAD", "equivalents": [ { "amount": 2550, "currency": "USD" } ] }

Himmel picks no rate and converts nothing: the rules read your figure, so "the assistant refunds up to $30" means $30 whatever your customer paid in, and a refund and the order it is for are compared in one currency. An amount sent without the figure its rule set reads is not an error. Where a rule needs it, the answer is undetermined_missing_facts, naming the amount in missing with the currency it is wanted in; an action you took without it still counts toward its customer's counts, such as "two credits in any 90 days", and you send the figure by completing the action. An action that rule sets in two currencies read — your policy in dollars over a law in euros — carries a figure for each. Refused with 422 invalid-fact, naming the fact: a currency ISO 4217 gives no decimals, such as gold (XAU) or XXX, for an amount or any of its figures (code currency); a figure in the amount's own currency, or two in one (equivalents); and a key a money value does not have (type), so a misspelt equivalent is never dropped without a word.

Recipients

Send a recipient as a descriptor — name, org, email, kind (person, the default, or organisation), and the customer or supplier number where you have one (customer_number, supplier_number, vendor_number, creditor_number) — or as an id an answer gave you. A customer you know only by email address can be sent by address alone: the same address is the same customer. A descriptor carries those keys and no other, each value a string of at most 200 characters (an address 254; a number may be a whole number), and never beside an id: a key it does not have is refused with 422 invalid-fact, code unknown_key, naming it - so a misspelt customer_numbr is never dropped without a word - and so is an id beside a name (described_and_named). A descriptor is replaced by a token before anything is stored, and it resolves to one identity per account, so a yearly total follows the recipient rather than the spelling. When two records might be one person, Himmel asks rather than guessing: see Recipients.

The answer

Every answer carries the same core:

And then what its state adds:

{ "state": "undetermined_missing_facts",
  "missing": [ { "fact": "recipient", "description": "Who received the gift", "needed_by": "de_gifts_entertainment.gifts.limit" } ] }

{ "state": "not_covered",
  "reason": "awaiting_confirmation",
  "unconfirmed_rules": ["de_gifts_entertainment.gifts.limit"] }

reason is one of awaiting_confirmation, rule_flagged, policy_gap, no_rule_matched, no_rule_set_for_jurisdiction or rule_set_broken.

rule_set_broken is an action that happened whose rules could not run on its facts - a rule that divides by a figure that is zero, say. Whatever its rules can say, an action you report as taken happened: it is kept, counts in every total, and your account is told (check.rule_set_broken, Alerts); detail names each rule set by its version and what the rules said, never a value you sent; and it is checked again once a version that can answer it is confirmed. An action you ask about before taking it is answered 500 rule-set-broken instead, and nothing is kept: nothing has happened.

Two checks of one account sent at the same moment are answered one after the other: the second waits for the first and reads what it stored - so two credits sent at once against "two in any 90 days", after one, are answered allowed and not_allowed, never both allowed. Other accounts never wait on yours.

A total counts every action it covers, whether or not it can read what the action came to: "two credits in any 90 days" counts a credit you gave without its amount. What such a total adds up to is not known until that amount is, so an answer that needs it names the fact with of, the action it is missing from — its transaction_id and effective_date — as in { "fact": "amount", "currency": "EUR", "of": { "transaction_id": "txn_01J8...", "effective_date": "2026-01-05" } }. A missing amount says the currency it is wanted in: its rule set's. Send it by completing that action, not in this check: the answers it reached are then issued again.

A fact you send as null is recorded as none, which is not the same as leaving it out — until a rule needs its value. Where a rule has to order it, add it, or take it as true or false, the answer names it in missing as it names a fact left out, and a fact the rule set requires is missing whenever it is null. Where your rule set says what none means — approved_by: null for a refund nobody approved — the rules read it as it is. The check keeps the facts as you sent them, the null included.

{ "state": "contested",
  "question": { "id": "de_gifts_entertainment.q.appropriate",
                "candidates": ["appropriate", "not_appropriate"],
                "reason": "Appropriateness is judged case by case, and this is above your per-person sign-off amount",
                "wording": "The law deducts only what is appropriate by general standards..." },
  "signer": { "user": "usr_01J9Q4TZ8M..." } }

A contested answer carries the rule's wording exactly as your rule owner confirmed it. signer is the Himmel id of the person your settings name for the question, never their name. Himmel never picks between the candidates: the named person does, and records it as a resolution. Where the question's rule says what each answer leads to, that decision answers the action again: the rules after the question answer too, and the new answer lists the decision it read in decisions.

Answers are as of a date

Some rules depend on earlier transactions: the limit on gifts is per recipient per fiscal year, across cards, invoices and reimbursements. Every answer says the date it is valid as of and the history it used. When a later booking changes an earlier one's treatment — a €30 gift in March is within the limit until a €25 gift to the same client in November takes the year over it — Himmel issues a new answer for the March booking before it answers November, with supersedes_check_id pointing at the old one, and raises a check.rechecked alert. November's answer lists it under rechecks. The old answer is never edited. A booking dated before answers already given works the same way, and the alert's reason says late_booking rather than later_transaction.

Proposals

An action checked before it is taken is status: "proposed". It is answered exactly as if it had happened, but it moves nobody's total, so asking does not change the answer to the next question.

It is dated the day it is asked: its date - the one the rule set reads as the action's own, action_date in the sandbox's playbook - is today, in UTC, a day either side for time zones. An action reported after it happened may be dated earlier, and none is dated after the day it is sent. Otherwise the check is refused with 422 invalid-fact, naming the date and the days it may have (not_the_day_asked, after_the_day_sent). An action you asked about keeps the day you asked when you complete or correct it later.

When the action has happened, or will not happen, report it:

curl https://api.gethimmel.com/v1/checks/chk_01J8.../execution \
  -H "Authorization: Bearer $HIMMEL_KEY" -H "Content-Type: application/json" \
  -d '{ "executed": true, "ref": "CN-2025-0311", "system": "expenses" }'

executed_at says when it was done, a moment with its offset that places the action in its day: between when you asked and this report, a minute either side for clocks that differ, else 422 invalid-request (before_it_was_asked, after_it_was_reported). Left out, it is the moment of the report.

On executed: true the transaction joins history at that moment, and any earlier answer whose totals it changes is issued again, with an alert. On executed: false — with the reason abandoned, refused_by_caller or failed — it is closed and never counts. ref is your own reference for the action taken — a credit note's number beside the ticket's — opaque like transaction.ref: one that looks like an email address or an IBAN is refused with pii-in-facts. It is kept beside the action's own reference, never over it: GET /v1/checks/{id} shows it as execution.ref, each row of the log as transaction.executed_ref, and the log finds the action by either (ref=); a report of an action not taken keeps none, and a repeat of a report answers with the first one's. system is where the action was taken: sent the same as the check's, or left out — another is refused with changed — and where the check named none, the report names it for the action. A repeat of a report names no system the action does not have. A proposal nobody reports on within 24 hours is closed as expired, and a report after that is refused with not-a-proposal. A proposal never becomes history without being reported. A key made for an agent reports on its agent's own proposals: one on anybody else's is refused with 403 not-the-agents-action.

The action itself is checked again when you report it done, as it stands then. The answer you were given is the answer of the moment you asked; if, while the action was open, another booking joined its totals — a colleague's credit to the same customer, say — or your rule owner confirmed a new version or corrected a setting, the report answers the action again, and where that comes out otherwise the new answer replaces the one you were given (supersedes_check_id, recheck_reason: proposal_executed), with a check.rechecked alert where its state or outcome changed. The report's response names it in superseded_by, which is empty where your answer stands as it was given; the answer you were given stays on record, unchanged. A change your rule owner has not confirmed yet never takes an answer away: your answer stands until they confirm it, and their confirmation checks it again.

Each report that changes the transaction is kept with who sent it — your key, or the person signed in to the console — and GET /v1/checks/{id} shows it under execution, beside the answer.

When an answer names a person

Where your rules give an action to a person — an approval above a limit, a question only a person answers — the answer names them by their Himmel id, and when an agent asked with a key made for it, Himmel asks them. The sandbox's sample playbook gives its team lead retention discounts above 15 %. Its assistant, asking with its own key before it offers a customer 20 %:

curl https://api.gethimmel.com/v1/check \
  -H "Authorization: Bearer $ASSISTANT_KEY" -H "Content-Type: application/json" \
  -d '{ "rule_set": "policy.sandbox.customer_support",
        "transaction": { "status": "proposed", "ref": "CASE-5001" },
        "facts": { "action_date": "'"$(date -u +%F)"'", "action": "retention_discount",
                   "customer": { "customer_number": "C-1003" }, "discount_percent": 20 } }'

is answered determined, the playbook's layer needs_approval with the team lead as its approver, and beside the answer requests, whom Himmel asked:

"requests": [ { "id": "apr_01J9...", "asked_of": "usr_team_lead", "asks": "approval", "status": "waiting",
                "asked_at": "2026-10-12T16:08:26Z", "waits_until": "2026-10-19T16:08:26Z", "...": "..." } ]

Himmel emails the person asked within a minute, at the address they sign in with, linking a page of the console where they approve or refuse, signed in (Resolutions). The request waits a week at most, until waits_until, and the proposal waits with it, so your agent can tell whoever it acts for when it will have been decided by. Meanwhile:

• It never asks the person itself. Only their answer in Himmel counts: an approval the agent got some other way is never read, and a check that names who approved is refused (An agent never names a person).
• It hears what they decided by asking again, naming the action (Asking again) and sending only the facts an answer asked for. Once the team lead approved, the assistant asking again is answered allowed, their approval listed in the answer's decisions. Refused, the answer stays needs_approval, requests says refused, and nobody is asked about the action again. Asked before they decide, the answer is as it was and the request still waits. Through the API, GET /v1/approvals/{id} says where a request stands without asking again; through the MCP server the agent asks again with the check_id of an answer to the action.
• It reports what became of the action, as for any proposal.

An action handed to a person. Where your rules hand an action to a person and name them - a rule's to, as the template's clause 2.7 names the team lead - the playbook's layer says whom, handed_to, beside approver. When an agent asked with its own key, Himmel tells that person once, by email and on Home (check.handed_over, Alerts): a notice, never a request - nothing waits on them in Himmel, nobody approves anything for it, and they act in your own systems. The agent asking again about the same action tells them nothing new.

A contested answer's question is asked the same way, of its signer (asks: "question"). Himmel asks only when an agent asked with its own key: your own software and your people keep their approvals in their own systems and send them as approved_by — the same 20 % discount sent with the sandbox's own key, naming the assistant in transaction.actor, is undetermined_missing_facts, asking for approved_by, and nobody is asked. And an approver is asked only where your rule set marks the fact that records who approved (approved_by, approval: true), so that their approval can be read: an answer that names a person with no requests asked nobody.

Trying it in the sandbox. The sandbox's team lead and head of support, usr_team_lead and usr_head_of_support, are people of the sandbox whom nobody signs in as, so a request made of either waits its week and lapses. To see an approval through, an admin of the sandbox, its playbook confirmed, names themselves the team lead from today — in the console's settings, under "Say who decides", or with PUT /v1/tenant-facts/support_team_lead, its value their own Himmel id (Your settings) — before the assistant asks. The assistant's discounts asked from then name them: they are emailed, approve on the request's page, and the assistant asking again is answered allowed. An action asked about before keeps the day it was first asked, and the team lead of that day. A key of the assistant's own is made as any agent's is (A key of its own for every agent).

Asking again

An action you are still asking about is asked about again by naming it: send the check with status: "proposed" and the action's booking in transaction.completes, by the transaction_id its latest answer carries:

curl https://api.gethimmel.com/v1/check \
  -H "Authorization: Bearer $HIMMEL_KEY" -H "Content-Type: application/json" \
  -d '{ "rule_set": "policy.acme.customer_support",
        "transaction": { "status": "proposed", "completes": "txn_01J8..." },
        "facts": { "delivered_on": "2026-10-07" } }'

It is the same action, asked again. Its facts are the booking's with the ones you send added — the fact an answer asked for, say — and a fact it recorded is left out or sent the same: a larger refund is a new question, which an approval of the smaller one does not cover, and is refused with changed. So send only the facts an answer asked for, or none: the action keeps the rest, and the day you first asked. Its day read again as today, a day later, is refused with changed too, the refusal naming the fact to leave out. Its answer replaces the one that stood, so the check log lists the action once, and it reads what was decided on the action since you last asked: where the person an answer named approved, or decided its question, while you waited, you are answered with their decision. Nobody it names is asked again — a request still waiting is the one it was, and requests says where it stands — and a person who decided is not asked again. It keeps the day you first asked, and the 24 hours before a proposal nobody reports on closes run from your latest asking. Report what became of the action on any of its answers: the check_id you kept from your first asking reports the action as it stands.

Asking again is for an action still being asked about, named by the booking that stands for it, in the run it was asked in: one taken is refused with not-a-proposal — send the facts it lacked by completing it — one closed without being taken with action-not-taken, one taken back with action-taken-back, and a booking already asked again with answer-replaced, naming the booking that stands (transaction_id) and its answer (standing). What the action was is held as for a completion: anything said otherwise is refused with changed. A question asked again without naming the action is a new action: answered on the books as they stand, with a request of its own, the person it names asked again.

Taking an action back

An action taken can be taken back afterwards — a credit given by mistake and clawed back, a refund whose payment failed. Report it on any answer the action has, the check id you kept or a later one:

curl https://api.gethimmel.com/v1/checks/chk_01J8.../reversal \
  -H "Authorization: Bearer $HIMMEL_KEY" -H "Content-Type: application/json" \
  -d '{ "reversed_at": "2026-03-11T09:00:00Z", "ref": "CB-2026-0311" }'

Both fields are optional: reversed_at is when it was taken back, else the moment you report it; ref is your own reference for taking it back, opaque like transaction.ref. From then the action counts toward nothing: every total it was in is worked out again without it, as if it had never been taken, and each earlier answer that moves is issued again (recheck_reason: reversal), with a check.rechecked alert where its state or outcome changed — those of actions that came while it stood included. So a customer's third credit of a day, refused while a mistaken first one stood, is answered again as the second once the mistake is taken back. Its own answers stay as they were given, and every earlier answer is still given back from its record.

Take an action back this way, never by booking its negative: a credit of -€15 is an action of its own, which a count of credits counts. The log lists an action taken back with transaction.status reversed and reversed_at; GET /v1/checks/{id} shows reversal on every answer to it — when, your reference, and who reported it — and it waits on nobody: a decision on it is refused with action-taken-back, and so is completing it. An action still being asked about is reported taken or not instead, and one never taken has nothing to take back (action-not-taken). Reporting it twice the same way is answered the same way; a report that says another moment or reference is refused with conflict. A key made for an agent takes back its agent's own actions; anybody else's is refused with 403 not-the-agents-action, and is for your account's own keys or your people to take back.

Completing an action

An action taken without a fact its answer needs — a credit given before its amount was known — waits on that fact. When you have it, send it as a check that names the action in transaction.completes, by the transaction_id its answers carry:

curl https://api.gethimmel.com/v1/check \
  -H "Authorization: Bearer $HIMMEL_KEY" -H "Content-Type: application/json" \
  -d '{ "rule_set": "policy.acme.customer_support",
        "transaction": { "completes": "txn_01J8..." },
        "facts": { "amount": { "amount": 1000, "currency": "EUR" } } }'

The check's facts are the booking's with the ones you send added, and the complete booking stands in for the first in every total: the first leaves the totals it was in, the complete one joins, and the answers either reaches are issued again. Both stay on record. The answer replaces the one that stood for the action — its supersedes_check_id names it, and the old answer's superseded_by names the new one — so the check log lists the action once, with the complete answer, and the review queue stops waiting on the fact. A decision your people made on the old answer carries over where the new one asks the very same question.

It is the same action. Its ref, run, system, channel, actor, provenance, jurisdiction and policies, and when it happened, are the booking's: leave them out, or send them as they were. A run is never given where the booking had none: every booking of an action sits in its one run. A system may be, where the action had none, and every booking of the action then carries it. The reference your report sent for the action taken is carried too. A key made for an agent completes the actions its agent took, and anybody else's is refused with 403 not-the-agents-action. And a completion adds facts; it never changes one: a fact the booking recorded a value for is left out or sent the same — a recipient as the same customer — while one left out, or sent as null, may be given. An amount it recorded may be sent again with the figures it lacked in other currencies (equivalents), which are added to it; a figure it recorded is sent the same or left out. Anything said otherwise is refused with invalid-request and the code changed, naming the field and never its value. An action still being asked about is asked about again instead, the check sent as proposed, and one already completed is completed by the check that completed it: answer-replaced names that booking and its answer.

Correcting an action

An action whose facts were sent wrong — €25 where €15 was given, another customer's number, the wrong day — is corrected, never sent a second time: a second action would count beside the first. Send a check that names it in transaction.corrects, by its transaction_id, with the facts as they should have been:

curl https://api.gethimmel.com/v1/check \
  -H "Authorization: Bearer $HIMMEL_KEY" -H "Content-Type: application/json" \
  -d '{ "rule_set": "policy.acme.customer_support",
        "transaction": { "corrects": "txn_01J8..." },
        "facts": { "amount": { "amount": 1500, "currency": "EUR" } } }'

The check's facts are the booking's with the ones you send in their place — one sent as null recorded as none, as a check records it, and an amount with the figures you send beside it — and provenance likewise. The corrected booking stands in for the first in every total, as a completion's does: the first leaves the totals it was in, the corrected one joins its own, and each earlier answer either moves is issued again with recheck_reason: correction and an alert where its state or outcome changed. Its answer replaces the one that stood, so the check log lists the action once, with transaction.corrects on its row, and the answer to it as first sent stays on record, one click away. Part of an amount taken back is the amount corrected.

It is the same action: its ref, run, system, channel, actor, jurisdiction, policies and when it happened are the booking's, and anything said otherwise is refused with changed — a run given where the booking had none included; a system may be given where the action had none, for every booking of it. An action that was another thing than you sent — checked against the wrong rule set, done by somebody else — is taken back and sent again. A decision your people made on the answer to the facts as first sent is asked again, since the facts it was made on changed; it stays on the answer it was made on. A correction that changes nothing is refused with unchanged, one sent with completes too with both; an action still being asked about, one taken back, one completed or corrected already, and from a key made for an agent one its agent did not take, are refused as a completion of them is.

Retries

Send an Idempotency-Key header with a check, and a retry with the same key and the same body gets the same check_id back — never a second check, and never a second proposal. The same key with a different body within 24 hours is refused with idempotency-conflict. Keys are per environment: the same key sent with a test key and with a live key is two requests. Every other POST that changes something takes a key the same way: see Getting started.

Reading answers back

GET /v1/checks/{id} returns the answer as it was stored, with superseded_by when a newer answer has replaced it, and resolutions, every sign-off and override your people recorded on it in the order recorded, with resolution the latest — one carried over from the answer before, the question unchanged, names the answer it was given on in given_on. Beside it, never inside it, come three more. facts are the facts the booking was sent with, as stored: a recipient by the id it resolved to when it was sent, never a name, and everything else as you sent it. They are the booking's, so every answer to it shows the same; the answer's own recipient says which identity that answer used. sent_by says who sent the check: {"kind": "api_key", "id": "key_...", "prefix": "hk_live_7f3a", "name": "support tool"} for a key — its prefix and the name it was given, never the key — or {"kind": "person", "id": "usr_..."} for someone signed in to the console. That is not always who acted: your software names who acts in transaction.actor, and someone trying an agent's example in the console sends it as themselves. An answer Himmel issued again was sent by nobody, so its sent_by is null and recheck_reason says why. An answer that completed an action was sent by whoever sent the completion, though it replaced the answer before it. For an action asked about before it was taken, execution says what became of it: its status now (proposed until you report, then executed, abandoned or expired), executed_at or the reason it was not taken, ref, the reference your report sent for the action taken, system, the system it is taken in as its check or its report named it, and who reported it and when. The answer itself still says proposed, because that is what was answered. GET /v1/checks is the check log, newest first, fifty to a page. It holds every answer ever given, those a later answer replaced included; current=true keeps only the answers that stand, one per booking. state and outcome take several values, separated by commas. Where our law answers, outcome is the law's; policy_outcome=not_allowed (or several, separated by commas) lists what your policy answered, whatever the answer as a whole says. missing=recipient keeps the answers that ask for that fact, consequence=non_deductible_amount those that carry that consequence, rechecked=true those that replaced an earlier answer, and rerun= those one re-run issued again when the rules changed (see Confirmations). It also filters by rule set, actor and transaction status.

To find an action the way your own systems know it:

To find what waits on somebody at your company:

A parameter the log does not take is refused with 422 invalid-request, naming it in errors[].field (code unknown_parameter), rather than ignored, as on every endpoint: a misspelt filter never reads as no filter at all.

The log lists the newest answer first. With order=effective_date it lists by the day each action happened instead, newest first — within a day, the action asked about or booked last comes first, and one booking's answers newest first — so an answer issued again never moves its row, and last year's bookings sent today sit under last year. With current=true that is one row per action. before continues either order from the last page's next_before.

Each row of the log carries what a list needs without opening every answer: sent_by, as above; transaction.amount, what the booking was for — the fact its rule set names as its amount, for our German gifts rule set what it was booked at, tax included, with the figures you sent beside it (equivalents), and nothing where the rule set names none; transaction.measures, what the action came to in another measure than money - each whole number a figure your rule set marks as approved covers, by its fact, such as a retention discount's {"fact": "discount_percent", "value": 20} where your policy marks approved_percent: { type: int, approval: discount_percent } - and [] where it marks none; layers, what each rule set made of it, law first — its kind, rule_set, state and outcome, so a list of what your policy found shows the policy's verdict where the answer's outcome is the law's, the rule that gave it that answer or asked its question, and the approver its answer names where it needs_approval; for an answer that is not settled, what it waits on — missing (the facts it asks for), reason (why it is not covered) or question (what a named person decides), with signer, who decides it; superseded_by, the newer answer that replaced it; and resolution, the latest sign-off or override recorded on it.

A row's transaction also says what belongs to the action rather than to the answer, since an answer is issued again whenever what it depends on moves: sent_by, who sent the action — the key or the person that sent its first answer — where the row's own sent_by is the answer's and empty on an answer issued again; resolution, the latest sign-off or override recorded on any answer to the booking, with the check_id of the answer it was recorded on — an earlier one when the answer has since been issued again asking another question, for a decision carries over only where the very same question is asked again (see Resolutions); run, the run of an agent it was part of, where its check named one; system, the system it was taken in, where one was named; ref, the action's own reference, and executed_ref, the one your report sent for the action taken; and facts, the facts it was sent with, a recipient by its id.

{
  "rule_set": "de_gifts_entertainment",
  "transaction": {
    "channel": "agent",
    "status": "executed"
  },
  "facts": {
    "booking_date": "2023-03-14",
    "account": "4630",
    "recipient": "r1",
    "amount_net": {
      "amount": 2000,
      "currency": "EUR"
    },
    "amount_gross": {
      "amount": 2380,
      "currency": "EUR"
    }
  }
}

{
  "rule_set": "de_gifts_entertainment",
  "transaction": {
    "channel": "agent",
    "status": "executed"
  },
  "facts": {
    "booking_date": "2023-03-14",
    "account": "4650",
    "participants": [
      "r1",
      "r2"
    ],
    "participants_recorded": true,
    "restaurant": true,
    "invoice_attached": true,
    "amount_net": {
      "amount": 9500,
      "currency": "EUR"
    },
    "amount_gross": {
      "amount": 11305,
      "currency": "EUR"
    }
  }
}

{
  "rule_set": "de_gifts_entertainment",
  "transaction": {
    "channel": "agent",
    "status": "executed"
  },
  "facts": {
    "booking_date": "2023-03-14",
    "account": "4630",
    "recipient": "r1",
    "amount_net": {
      "amount": 2000,
      "currency": "EUR"
    },
    "amount_gross": {
      "amount": 2380,
      "currency": "EUR"
    }
  }
}

{
  "rule_set": "de_gifts_entertainment",
  "transaction": {
    "channel": "agent",
    "status": "executed"
  },
  "facts": {
    "booking_date": "2023-03-14",
    "account": "4650",
    "participants": [
      "r1",
      "r2"
    ],
    "participants_recorded": true,
    "occasion_recorded": true,
    "restaurant": true,
    "invoice_attached": true,
    "amount_net": {
      "amount": 50000,
      "currency": "EUR"
    },
    "amount_gross": {
      "amount": 59500,
      "currency": "EUR"
    }
  }
}