Nobulex is an open-source gateway prototype designed to sit between an automated system and execution. It evaluates financial evidence, applies deterministic policy, and returns PERMIT, BLOCK or ESCALATE with a receipt. It is not deployed in production. Signing is off by default: with a key configured the receipt is Ed25519-signed, and without one it is marked UNSIGNED.

How is this different from an agent guardrail?

A guardrail decides whether an agent is allowed to call a tool. Cloud agent gateways already do that well, including limits on parameters such as dollar amounts. Nobulex asks a different question they do not answer: are the financial facts this action depends on true enough to risk money.

How is this different from data observability?

Observability platforms watch a data estate and alert on freshness, completeness and schema anomalies. Nobulex binds evidence to one specific proposed action at the moment money is about to move, and can stop that action. They are complementary; Nobulex sends its decisions to your existing monitoring.

Does a signed receipt prove the data was true?

No. A signature establishes that one key signed a specific decision object containing the action, policy version, evidence identifiers and verdict. The current prototype does not bind that key to a durable public identity. The financial evidence establishes the factual basis, and cryptography cannot turn a false source into a true one.

What is INDETERMINATE?

A first-class third state for when truth cannot be established. Halts, crossed feeds, late corporate actions and vendor disagreement can all make an honest answer impossible. Nobulex reports that rather than guessing, and policy decides whether to escalate, block or allow and log.

Do I have to let it block production traffic on day one?

No. Observe Mode computes the full verdict and never blocks. You see what would have been stopped against real traffic, calibrate the false-block rate, and enable enforcement on one bounded action type only when the numbers justify it.

The gateway prototype

A separate line of work from the billing replay study on the home page. It checks evidence about a proposed action, evaluates a bounded policy, and returns permit, block or escalate. It is a prototype: not deployed in production, and there is no 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 bps

Evidence 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.

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.

Evidence

PASS

The facts were checked against independent references under a declared method and held within the configured tolerance.

Evidence

FAIL

The evidence was checked and did not hold. Stale beyond tolerance, mis-scoped, incomplete, or contradicted by reference sources.

Evidence

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.

Decision

PERMIT

Evidence held and the policy was satisfied. The action proceeds to the broker or tool, and the receipt records why.

Decision

BLOCK

The action does not execute. The reason codes name exactly which check failed and what the observed and configured values were.

Decision

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.