Agents propose.
Your policy decides.
An agent proposes an action: a purchase, a transfer, a subscription, a repayment, now. Neumetria assesses the person for that specific act, executes the policy you published against the assessment, and answers inside the turn. The outcome words, the ceilings and the reason codes are yours.
A band reads the person.
An action is specific.
Readiness describes the person: whether this is a moment for spending, saving, investing, or none of them. It does not answer whether an agent may spend €1,200 at this merchant right now. That question needs the action itself, and a rule you wrote about it.
An agent acting on someone’s behalf asks what a lender asks about a loan: does this person’s position support it. The difference is the clock. A lender has days. An agent has the rest of the turn.
So the assessment and the policy run together, against a fact snapshot written before the answer returns. Nothing is recomputed later against signals that have since moved, which is what makes the run readable a year afterwards.
Capacity is the room left uncommitted over the weeks ahead, once what falls due and what the person needs to live on are set aside. Expected income inside the window is left out on purpose, because a reading that over-reports room lets money out of the door. It can be negative, and that is the most useful thing it reports.
When an input is absent, stale, or in a currency the others do not share, no number is served and the missing input is named. An amount whose unit is unknown is worse than no amount. Your policy routes an abstention to the branch you wrote for it.
When the pipeline has flagged the person as deteriorating, money going out is not assessed, the reading is marked as overridden, and the figure it would have produced is kept beside it, so a reviewer can tell a distress override from a thin file. A repayment or a withdrawal reduces exposure and is read as normal.
Two calls,
inside the turn.
Assess the person for the action. Execute your policy against that assessment. Nothing is queued and nothing is polled.
Nine kinds of action, in three families. Each is answered by the figures its own inputs support: a purchase against the room the person has today, a subscription against the commitments already carried, a repayment against the room it frees.
A one-off purchase, a new recurring commitment, or a transfer to a person, a bill, a lender or another account. Send whatever merchant name the agent holds; resolving it to the entity we know is our job, not yours. A subscription is read as the commitment it is, not as its first payment.
A credit action carries its instalments and cadence, so a borrowing question reaches the same rule engine and the same record as the purchase beside it. A repayment reduces exposure and is assessed as one, against the room it frees.
Money moving into savings, a one-off or recurring allocation, a position, or money coming back out. We take an asset class, a size and, on a trade, its risk shape: long or short, cash or margin, option legs. A ticker, an ISIN or a token address is refused, not stripped, so the asset’s identity never reaches the record.
Every word in that response is yours. ALLOW_WITH_LIMITS is an outcome you declared, RENT_DUE_4_DAYS a reason you named, and the ceiling is the value of a rule you wrote, resolving against a measurement we served.
// illustrative evaluation response { "outcome": "ALLOW_WITH_LIMITS", "reasons": ["RENT_DUE_4_DAYS"], "constraints": { "max_amount": 640.25 }, "matched": { "kind": "rule", "rule_id": "near_large_obligation" }, "policy": { "key": "agent_spend", "version": 4 } }
Signed,
and checkable offline.
Turn on receipts for a policy version and every run it answers comes back signed, carrying your outcome and your constraints. Whoever you hand it to can check it against our public keys without calling us.
A receipt is tied to the exact action proposed, the facts the policy ran over and the version that answered. Alter the amount, the merchant or the outcome afterwards and it no longer verifies.
A receipt answers for this turn, not for next week. The lasting evidence is the run itself, kept with the facts it read and retrievable whenever someone asks.
The outcome and constraints inside are the ones your policy returned. A receipt proves which policy ran over which facts. It does not prove the facts were true, and it carries no reasons and none of the facts it read.
Automated,
and said so.
An answer inside the turn has nobody to wait for. Action policies publish in automated mode only: a blocking review is refused at publish rather than recorded as one that never happened.
You record the Article 22(2) basis on the version and it is frozen there. A share of runs that you set reaches a person after the fact, so your override rate stays measurable on the highest-volume surface you run.
A post-hoc review records agreement, or disagreement, with an outcome the caller already acted on. It is never presented as a review that prevented one.
We execute your policy.
We never decide.
The outcome words are yours.
Neumetria has no vocabulary of allow or block. We supply the measurement and run the rule you wrote against it; every string that comes back is one you authored.
The caller is your platform, never the consumer’s own assistant. Serving a spending ceiling to a person’s shopping agent would be advising a consumer about their money, and that is the boundary this company does not cross.
Nothing here carries a calibrated reading, and no purchase produces an outcome label to learn from. Where learning happens, it happens on credit.
Teams whose agents act on money and want a rule that runs before they do, not a paragraph in a system prompt.
Teams putting an assistant in front of real accounts, with a published limit behind it and a record of every time it applied.
Teams already running a credit policy here, extending the same engine to the checkout an agent drives.
