Send activity.
Read the person.
You choose the oversight.
Two calls carry the integration. One streams activity in. One reads the current financial state and its readiness gates back out. Publish a policy and we execute it on your rules, under the oversight you set — held for a reviewer, sampled, or automatic.
Activity in.
Understanding out.
Your product already has the stream. Neumetria sits under it: ingest, interpret, keep the financial state current, expose readiness. Nothing about how you use the answer lives on our side.
as_of. Optional gate bundle for spend / save / invest / quiet.Verdicts return, too. Confirmations and corrections your product sends back are stored and re-applied whenever the understanding recomputes — the view revises; it does not reset.
Understanding,
then gates.
The read surface is built for products and agents that need a person-shaped view before they paint a screen or plan a turn, not a dump of raw classifications.
A current behavioral view of the person: how they earn, spend, and hold, read in context, with confidence and as-of on each object.
Readiness for this moment: spend, save, invest, or stay quiet. A band describes the person, never a verdict on anything you offer. What a band means in your product is yours to define.
Every object carries the activity it came from, including how many observations sit behind it. When inputs are missing or stale, the answer says so and names the gaps instead of returning a confident middle value.
Illustrative shape only. Field names and nesting in the private preview may differ. We do not publish the full object catalogue here on purpose.
Authentication is API-key based per tenant. Actors are scoped to your tenant. We do not share behavioral views across customers.
// illustrative { "actor_id": "a_4f2a9e...", "as_of": "2026-07-22T09:41:00Z", "understanding": { "income_rhythm": { "shape": "biweekly", "stability": 0.91 }, "liquidity_horizon": { "days": 11, "confidence": 0.78 }, "behavior_drift": { "direction": "cooling", "since_days": 19 } }, "gates": { "spend_readiness": "moderate", "save_readiness": "hold", "invest_readiness": "hold", "stay_quiet": false } }
»» Gate names describe readiness for your product to read. They are not advice, and they are not a verdict on any product of yours.
We run your policy.
You choose the oversight.
You author the rule and you choose who signs off: every run reviewed by a named person, a sampled slice, or none. We execute the rule exactly as written and enforce the mode you picked — including refusing to run an automated policy until you have recorded the lawful basis you are relying on. What we never do is author the rule or pick the mode for you.
What we will not do
- × Write, suggest or tune a rule for you
- × Choose your oversight mode for you
- × Let an API key resolve a review a person owes
- × Invent an outcome when a review expires
- × Approve, decline, price or limit anything
What comes back
- ✓ Readiness bands of the person
- ✓ The evidence each band rests on
- ✓ Confidence and as-of on every object
- ✓ A frozen record of the inputs a decision saw
- ✓ Versions an old answer can be read under
The read still stands alone. A product screen and an agent turn query the same state without publishing any policy at all — executing one is a surface you opt into, not a prerequisite for the answer.
And the duty of care stays where it already sits. You hold the customer relationship, the obligation and the choice — including the choice to decide automatically, which is lawful and which we support. It does not reduce what you owe: a solely-automated decision needs its own basis, and the rights to human intervention, an explanation and to contest stay live. Those endpoints are always on and are not configurable.
»» We author no policy and decide no outcome. If a page anywhere suggests Neumetria approves, declines, prices or limits, that page is wrong.
Ship a rule
the way you ship code.
A published version is immutable, so every change is a new version rather than an edit. Each one is checked before it can go live, and the whole check report is stored on the version — what we verified is answerable years later instead of being a property of whichever analyser happens to be deployed when someone asks.
Publishing is blocked on an unknown fact, an operator the fact’s type does not allow, an out-of-range threshold, an outcome you never declared, a rule that could never fire, and a rule another one already covers. The table is flat and evaluated in order, which is what keeps those last two a finite check rather than a proof obligation.
Replay a candidate over the assessments you actually served. The engine does no I/O by module rule and the assessments are stored verbatim, so the replay reproduces what would have happened — a statement about your last quarter, not an illustration. You get simulation before you get publish.
Static analysis proves a document is coherent. It cannot prove the policy still does what you meant, which is exactly what a threshold change breaks. Name the cases that matter with their expected outcome and why, and they run through the same evaluator production uses — never a second implementation, which would eventually disagree in the direction of passing.
Rolling back publishes a copy of the older document and re-runs both the analysis and your cases, because a version publishable a year ago may not be now. It costs a row and buys the thing that matters afterwards: the history records that a rollback happened, when, and by whom.
»» Authoring and simulating without publishing is the ordinary state, not a half-finished one. Evaluating against a policy with no live version is refused outright rather than quietly falling through to a default.
Build against the contract.
Not against a promise.
The sandbox is a stateless mock of the same API, on its own host, reachable with test keys. It answers every route the production surface exposes, so a working integration can be written and tested before a single real transaction moves.
The mock covers the whole production surface, and a parity test diffs the two in both directions. A route added to the API fails the sandbox build until the mock follows, so what you built against cannot quietly fall behind.
No pilot data at rest and no enrichment cost. Responses are derived from the request, so shapes react to your payloads instead of replaying one canned example.
A test key reaches the mock and nothing else. Production is a separate key on a separate host, so an integration cannot half-switch by accident, and a stray sandbox call cannot touch real data.
The OpenAPI document is served by the API itself and rendered as a browsable reference, so it tracks the routes rather than being written alongside them. The sandbox publishes its own copy, unauthenticated.
»» The sandbox stores no pilot data. It shares infrastructure with the platform only to verify that your test key is valid.
Setup, security,
pricing, support.
// minimal ingest shape { "actor_id": "a_4f2a9e...", "transactions": [ { "amount": 52.40, "currency": "USD", "direction": "debit", "posted_at": "2026-07-19T10:24:00Z", "merchant_hint": "WHOLEFDS MKT" } ] }
Full OpenAPI, auth recipes, webhooks, and a step-by-step lending walkthrough come with preview access. Write with your product, the surface you are starting from, and the environment you want to build in.
We work directly with your engineering lead through the first integration. Sandbox first, staging next, production when the shape is settled.
Two calls. Your rules. Your oversight.
If you are building lending, product surfaces, or financial agents on a current financial state, talk to us and we will get you a sandbox key.