PASS
The facts were checked against independent references under a declared method and held within the configured tolerance.
N O B U L E X
Billing replay study
Billed $50. Expected $150.
The issue reporter says the dry run repeated a wrong $50 invoice. Our released-tag H2 test reproduced the $50 invoice against the latest $150 catalog price. We are testing an independent check of that gap.
Proposed $2,500 study. One scenario, one expected amount, one release test. No customer deployment yet.
CURRENT BUYER QUESTION
When a billing preview and final invoice agree on the wrong amount, what independently checks the approved price before issuance?
Read the reproduced Kill Bill case Tell us how you check invoice amounts before releaseThis is research, not a deployed billing product or a customer result.
THE DECISION
Schema validation proves shape. Nobulex verifies the decision.
An automated system proposes an action. Before it reaches the broker, Nobulex asks two independent questions: are the facts trustworthy, and is the action permitted. Open each case to see the request, the evidence and the decision.
Illustrative examples, not live decisions. These show the shape of the decision object and the reason codes. This page does not contact a market-data provider, evaluate a policy or execute an order.
Three proposed actions. Open each to inspect it.
Fresh quote, within policyPERMIT
The quote is 84ms old, two entitled references agree within tolerance, and the notional sits under the configured limit.
Proposed action
broker.order.create symbol AAPL side buy quantity 100 limit_price 241.30 notional $24,130
Evidence
quote age 84 ms max age 1000 ms references 2 sources max deviation 2.1 bps tolerance 10 bps
Evidence status PASS · Decision PERMIT · Reasons QUOTE_FRESH, REFERENCE_CONSENSUS, POLICY_NOTIONAL_WITHIN_LIMIT
PERMIT covers the checks that were configured. It does not establish that the strategy is sound.
Valid JSON, stale priceBLOCK
The response returned 200 OK. The schema validated. Every required field was present and the ticker was correct. The price was fourteen minutes old and both reference feeds disagreed with it by more than a dollar.
Proposed action
broker.order.create symbol AAPL side buy quantity 1000 notional $241,110
Evidence
primary feed 241.11
(14m 22s old)
reference A 243.08
reference B 243.11
deviation 81 bps
tolerance 10 bpsEvidence status FAIL · Decision BLOCK · Reasons QUOTE_STALE observed_age_ms=862304 maximum_age_ms=1000, REFERENCE_DISAGREEMENT
Nothing crashed. Nothing raised. A schema check cannot distinguish this response from a correct one.
Truth cannot be establishedESCALATE
The security is halted and the two references disagree because one has applied a corporate action the other has not. Neither source is wrong. The honest answer is that the question cannot be settled right now.
Proposed action
broker.order.create symbol EXMPL side sell quantity 5000
Evidence
market state halted reference A 18.40 (adjusted) reference B 36.80 (unadjusted) split 2:1, effective today basis unresolved
Evidence status INDETERMINATE · Decision ESCALATE · Reasons MARKET_HALTED, CORPORATE_ACTION_BASIS_UNRESOLVED
INDETERMINATE is a real state, never reported as a pass. Policy decides whether it escalates, blocks, or on low-risk actions permits and logs.
The policy that produced these decisions
Policy is deliberately bounded: no loops, no network access, no unbounded computation. Over an authenticated and complete context, evaluation is deterministic and terminating by construction.
policy "equity-order-v1" {
permit broker.order.create
when evidence.market_quote.status == PASS
and evidence.market_quote.age_ms <= 1000
and action.notional_usd <= 50_000
and portfolio.daily_turnover_pct <= 5;
escalate broker.order.create
when evidence.market_quote.status == INDETERMINATE;
forbid broker.order.create
when evidence.market_quote.status == FAIL;
}An LLM may help you author a policy. It should never be the final arbiter of a hard limit on money.
What a pilot contains
One workflow, mirrored in Observe Mode with no execution impact. We replay a fixed suite of well-formed-but-wrong conditions against your path and show exactly which actions would have been stopped. You get the catch rate, the false-block rate and the added latency as measured numbers. If they justify it, enforcement goes on for one bounded action type, with explicit break-glass.
Run it against one path
Shadow mode on a single workflow, no execution impact, no platform migration. Tell us which action type matters most and which feeds you are already entitled to consume. Nobulex runs against data you already license; it is not a market-data reseller.
Agent gateways check whether a call is allowed · Observability watches the data estate Nobulex checks whether the facts behind this action are true enough to risk money.
- Evidence status and execution decision, kept separate
- INDETERMINATE is a real state, never a pass
- Deterministic policy, not a model's opinion
- Observe first, enforce on evidence
THE FAILURE
Financial software can be wrong without looking broken.
An API returns 200 OK. The JSON validates. Every required field exists. The ticker is syntactically valid. The system receives a plausible number.
But the price is stale. The security was mapped incorrectly. A time series silently lost its last twenty rows. Adjusted and unadjusted prices were mixed. The endpoint returned yesterday's close while presenting it as current. The tool returned an empty result where data should exist.
Nothing crashes. And that is exactly why the failure is dangerous. A person reading a price that is fourteen minutes stale may notice. An automated system will trade on it.
This does not require a future agent economy. Automated financial software already turns data directly into orders today, and AI assistants now run from research through to live deployment. The boundary where a number becomes a trade already exists. It is mostly unguarded.
One question governs every decision here: are the facts behind this action true enough to risk money?
EVIDENCE AND DECISION
Two questions, answered separately
Conflating "we cannot establish truth" with "the facts are false" makes an operational system brittle. Nobulex keeps the evidence question and the execution question apart, so a policy can treat them differently by risk.
FAIL
The evidence was checked and did not hold. Stale beyond tolerance, mis-scoped, incomplete, or contradicted by reference sources.
INDETERMINATE
Truth could not be established. Halts, crossed feeds, ambiguous symbology and late corporate actions are honest reasons to be unsure. Never reported as a pass.
PERMIT
Evidence held and the policy was satisfied. The action proceeds to the broker or tool, and the receipt records why.
BLOCK
The action does not execute. The reason codes name exactly which check failed and what the observed and configured values were.
ESCALATE
Routed to a human or an external approval path. Reserved for the cases where being unsure is the correct answer.
Defaults are risk-sensitive rather than globally fail-closed. On a money-moving action, FAIL blocks and INDETERMINATE escalates. On a low-risk read, INDETERMINATE can permit and log. The buyer configures which is which.
HOW IT WORKS
Inline, between the decision and the money
1
Action proposed
2
Verify the evidence
3
Evaluate the policy
4
Permit, block or escalate
5
Execute downstream
6
Issue the receipt
Evidence checks cover identity binding, freshness against the market calendar, completeness over the expected window, corporate-action basis, and agreement between independently entitled sources. The evidence timestamp is bound to the action and revalidated at the execution boundary, so a check cannot silently age out between approval and submission.
WHAT A RECEIPT PROVES
A signature establishes provenance, not truth
| A receipt does say | A receipt does not say | |
|---|---|---|
| Attestation | The holder of the identified key signed this exact decision object: action hash, policy version, evidence references, verdict and time | That the external world was correctly represented by those sources |
| Identity | Which key signed, by the key ID it carries | That the key has durable, publicly anchored provenance. There is no PKI or revocation behind it yet, so a signature today proves only that the same key signed twice, not who holds it |
| Evidence | Which sources were consulted, when they were observed, and the hash of each payload considered | That those sources were themselves correct. A false oracle signed is still false |
| Policy | Which policy version was active and how it evaluated over the supplied context | That the policy was the right policy. You author that |
| History | Each receipt carries the previous receipt hash, so tampering is evident to anyone holding a later checkpoint | That a chain held entirely by one operator cannot be rewritten wholesale. That needs an external anchor |
| Coverage | What passed through the gateway, including every signed break-glass override | Anything about traffic that bypassed it. Coverage is measured and reported, not assumed |
Receipts hold hashes and identifiers rather than raw market or customer payloads. That keeps licensing, privacy and retention exposure low while preserving the ability to prove which evidence set a decision rested on.
DEPLOYMENT
Nobody should let a new gateway block production on day one
So it does not. Observe Mode computes the full verdict and never blocks. You find out what Nobulex would have stopped, on your real traffic, before it has the power to stop anything. Enforcement is something you turn on once the numbers earn it.
- 1. ObserveMirror one path. Full decisions computed, nothing blocked, no execution impact
- 2. ReplayA fixed corpus of well-formed-but-wrong conditions runs against your path
- 3. MeasureCatch rate, false-block rate, added latency, and the share of live calls landing INDETERMINATE
- 4. Enforce, narrowlyOne bounded action type, or paper trading first, with explicit break-glass
- 5. ExpandMore feeds, instruments and action types under the same evidence and policy boundary
A safety product that causes an outage has failed at its own job. Per-action fail policy, cached reference state and local evaluation mean a gateway problem does not have to become a trading halt. You choose, per action type, whether unavailability fails open or closed.
WHY FINANCE FIRST
Because here the right answer is externally checkable
This method needs an independent oracle. Market data has unusually rich ones: multiple entitled sources, exchange calendars, settled identifiers, corporate-action records and execution confirmations. Most domains have nothing comparable. Starting where claims can actually be falsified is a feature, not a limitation.
- Identity bindingThat the instrument returned is the instrument requested, across symbology
- FreshnessAge against the market calendar and session state, not a fixed clock
- CompletenessThe expected observations for the requested window, so truncation is visible
- Corporate actionsSplits, dividends and the adjusted or unadjusted basis actually in use
- Source agreementIndependently entitled references, compared within a stated tolerance
Nobulex runs against feeds you are already licensed to consume and stores only the evidence metadata and hashes a receipt requires. It does not redistribute market data.
WHAT THIS IS NOT
An evidence and control layer, not a guarantor
Nobulex is not a broker, an investment adviser or a fiduciary, and it does not guarantee that any data source is correct. It establishes evidence under a declared method and reports PASS, FAIL or INDETERMINATE.
It does not claim that installing it satisfies any regulatory obligation. Supervisory rules continue to apply to the firm using it. What it produces is the control and the evidence a supervisor would want to see, not a substitute for supervision.
It is not a replacement for your observability stack, your broker's pre-trade risk controls, or your own tests. It sits at a different point than any of them: bound to one specific action, at the moment that action would execute.
Cryptography proves who attested to what. The financial evidence is what makes the attestation worth anything.
WHERE THIS STANDS
The honest state of it
Stated plainly, because a control product that oversells itself has already failed the only test that matters.
The checks
An open-source Python suite for completeness, window and truncation detection, with a fictional offline example and a published method. Runnable today.
The verdict discipline
Separate evidence and decision states, with INDETERMINATE as a first-class result rather than an exception path.
The gateway
The HTTP decision API and Observe Mode wrapper are implemented and tested locally. They are not deployed or running in anyone's production path.
Enforcement in production
No customer is blocking live orders through Nobulex today. Any claim otherwise would be the same kind of well-formed lie this exists to catch.
A trust score
No universal 0-100 rating for an agent. Reliability is reported per capability and per window, derived from receipts, or not at all.
A public registry
Verdicts are private to the buyer. Any aggregate register is downstream exhaust, with permission, and never a precondition for the product being useful.
The first buyer gets the entire benefit. No second participant, no network, no registry and no one else's adoption is required for this to be worth installing.
Adjacent research: a billing dry run can agree with a wrong final invoice. This is an upstream code study, not a Nobulex deployment or proof of buyer demand.
FAQ
Questions, answered
What is Nobulex?
A gateway between an automated system and execution. Before a financial action runs, it independently verifies the financial facts that action depends on, evaluates a deterministic policy, and returns PERMIT, BLOCK or ESCALATE. Every decision produces a receipt showing what was checked and why. Signing is off by default: configure a key and the receipt is Ed25519-signed, run without one and it is marked UNSIGNED rather than presented as signed.
How is this different from an agent guardrail?
A guardrail decides whether an agent is authorised to call a tool. Cloud agent gateways already do this well, including deterministic limits on parameters such as dollar amounts and session-scoped budgets. Nobulex asks the question they do not: are the financial facts behind this authorised action true enough to risk money. Generic policy is an ingredient. Financial evidence is the wedge.
How is this different from data observability?
Observability platforms watch a data estate and alert on freshness, completeness, schema and volume anomalies, and they are good at it. Nobulex binds evidence to one specific proposed action at the instant money is about to move, and can stop that action. Send Nobulex decisions to your existing monitoring; it is not trying to replace those dashboards.
Why would we not just build this ourselves?
You will build the first version yourself, and it will be about three hundred lines. Nobulex only deserves to exist if it becomes meaningfully better at the edge cases: symbology and entity mapping, market calendars, corporate-action basis, source disagreement, temporal validity, plausible truncation, and replaying those failures against your own path. The moat is the failure corpus and the evidence adapters, not the policy syntax.
Does a signed receipt prove the data was true?
No, and this matters enough to print in the documentation. A signature establishes that one key signed a specific decision object. The current prototype does not bind that key to a durable public identity. The financial evidence establishes the factual basis. Cryptography cannot turn a false source into a true one.
What happens if Nobulex goes down?
You decide in advance, per action type, whether unavailability fails open or closed. Local evaluation and cached reference state keep the common path alive. A control product that turns into an outage has failed at its own job, so this is configured before enforcement is ever enabled, not after an incident.
Do I have to let it block on day one?
No. Observe Mode computes the full verdict and never blocks, so you see what would have been stopped against real traffic first. Enforcement goes on for one bounded action type once the false-block rate is understood, with explicit break-glass, and every override is itself signed.
Is anyone running this in production?
No. The checks and the verdict discipline are built and open source; the inline gateway is the current work. Nobody is blocking live orders through Nobulex today, and this page will say so until that changes.
GET STARTED
Run it against one path, in shadow
No execution impact, no platform migration, no commitment to enforcement. Tell us which action type matters most and which feeds you already license, and we will show you what would have been stopped.
The market-data pilot and billing study are separate fixed-scope offers. Billing validation remains research; no customer has purchased the study, and no billing control is deployed.
The buyer pays. Nobulex is never funded by the data vendor or tool being checked, because the moment revenue depends on a subject's satisfaction the verdicts are worth nothing.
Corrections: nobulex.dev@gmail.com. If something on this page overstates what the software does, send it and it gets fixed in public.