Saved Successfully.

webcore fusion

Agent Readiness Suite

Autonomous AI agents are about to start shopping and booking against your NDC APIs. fusion asks the two questions that decision turns on: does your NDC implementation hold together, and is this channel safe to point an agent at?

The Two Lenses

Offer & Order Integrity Assurance

A defect list and a distribution decision are not the same document

Most test tooling produces one score. That is the wrong shape for this problem. An expired offer that silently reprices is a bug for the integration team. An offer that silently reprices when an autonomous agent accepts it is a commercial exposure. fusion reports both, separately, from the same run — so the engineering team gets a defect list and the distribution team gets an answer.

Coming soon

fusion is coming soon. The suite, the test case library and the order guards are built; carrier execution and report signing are in development. We are onboarding a small number of design partners who want to shape it — talk to us if that is you.

  • Offer integrity
  • Fare rules
  • Branded fares
  • Ancillaries
  • Order truthfulness
  • Agent pattern stress
  • Trust, scope & injection
  • Order state guards
  • CI gate
webcore fusion test case library listing agent pattern stress and offer integrity test cases with their isolated variable and severity

Carrier NDC API readiness

Does the implementation hold together?

The first lens is an engineering lens. Does a priced offer stay priced? Do fare rules and branded fare attributes survive the journey from shopping to order? Does an ancillary that cannot be fulfilled surface as a failure rather than a partial success?

Findings here are defects for the carrier's integration team, ranked critical, major or advisory, each tied to the single variable the test case isolated.

Agent readiness

Is this channel safe for an agent?

The second lens is a distribution lens. An autonomous agent retries, runs concurrently, fans out across permutations and will accept whatever it is told is true. That behaviour finds things a human tester never would.

Findings here are not a bug list. They are the input to a decision about whether to open the channel, and on what terms.

Inside the suite

Test cases as data, guards as functions, verdicts as evidence

Nothing in fusion is a compiled test method with an opinion buried in it. Test cases are data, each isolating exactly one variable. Guards are pure functions over order state. Every number in a report is a projection of run results, never hand-assembled.

Offer integrity

Does the offer mean what it says?

Fare rules, branded fare attributes and ancillaries checked from shopping through to order — whether what was displayed is what gets sold.

Agent pattern stress

The way an agent actually behaves

Replayed idempotency keys, concurrent acceptance of one priced offer, shopping fan-out cost, throttling that returns an empty offer set instead of saying it throttled, and cached offers that no longer price.

Order truthfulness

Confirmed means confirmed

Whether a partly fulfillable order is reported as fully created, and whether a confirmation is backed by a real order rather than an optimistic response.

Trust, scope and injection

The channel's boundaries

Whether a handle stays bound to who presented it, and whether content coming back through the channel can influence an agent it should not be able to reach.

G1 & G2

Priced offer, not expired

Order creation accepts only a priced offer reference, never a search-stage handle. Acceptance after the price guarantee expires returns a typed error — never a silent reprice, under any code path.

G6 & G8

Truthful, and bound

An order is reported confirmed only against a response carrying a real order, and an offer handle stays bound to the party that was shown it.

G3, G4, G5, G7

Specified, in development

Reprice as a separate decision, human confirmation above a material change threshold, mandatory idempotency keys, and one flight per priced offer. Specified in full so the gap stays visible.

Never overstated

4 of 8 implemented

A guard that is not implemented is never reported as enforcing. The product tells you what it does not yet cover rather than letting you assume it does.

Watch it run

Live progress

A run streams its progress as it executes, so a long suite is not a black box until it finishes.

Compare and diff

Regression against a baseline

Compare a run against a previous one and see what changed. A regression is a diff, not an impression.

Two scores, one report

Readiness report

Carrier API readiness and agent readiness, each broken down by category, with failures listed most severe first and the evidence attached.

Gate the release

CI integration

Start a run from a build pipeline, poll it, and act on a single verdict and exit code — so agent readiness sits in the release process rather than in an annual audit.

Demand and funnel

Search to offer to order

Where demand arrives, where it converts and where it leaks — measured over the same search, offer and order data the harness already observes.

Partner hierarchy

Aggregator, sub-agent, agency

Traffic attributed down a real partner hierarchy rather than flattened, so an aggregator's behaviour and its sub-agents' behaviour are distinguishable.

Usage and compute

What the channel costs

Shopping fan-out is not free. Usage and compute reporting makes the cost of serving a partner visible next to what that partner books.

Carrier-scoped throughout

By construction

Every query is carrier-scoped and redaction happens before a record leaves the carrier estate. Raw NDC payloads never sit in database columns.

Order state machine guards

What a run found, and what would have been stopped

A run tells you what the carrier did. The guards tell you what fusion would have prevented. They are pure functions over order state with no transport types on the surface — which means they can be reasoned about, tested in isolation, and are not quietly coupled to whichever protocol an agent happens to arrive on.

Each guard carries its specification in the product, including the ones not yet implemented, so the gap between what is enforced and what is intended is always on the page.

webcore fusion order state machine guards G1 to G8 with their specifications and implementation status
webcore fusion runs screen showing test case execution progress for a carrier profile

Built to sit inside the carrier

Your data does not leave your estate

fusion is carrier-embedded by design. Every query is scoped to the carrier, redaction happens in process before any record leaves, credentials are vaulted rather than configured, and raw NDC payloads are stored outside the database with only a path and a content hash kept in SQL.

It is a standalone application, deployed independently. It does not bundle the booking tool or the certification tool, and no harness or monitoring code goes anywhere near the products that run in airline production.

Works with

Part of the Webcore NDC toolchain

fusion is one of five Webcore products. These are the ones it sits next to.

webcore latitude

latitude proves your NDC integration works. fusion asks the harder question of whether the channel behind it is safe to open to an autonomous agent.

NDC Sandbox

webcore certifi

certifi certifies a named partner against a published programme. fusion assesses the channel itself, independently of who is calling it.

NDC Certification Tool

webcore nucleus

Findings become work. Readiness gaps can be tracked as a delivery backlog rather than a report nobody owns.

Project & Delivery Management

Shape it with us

fusion is coming soon. We are working with a small number of carriers who want agent readiness solved before the traffic arrives, not after.
Tell us what your distribution team is worried about.