Fixture Manifest

A portable audit trail for synthetic payment fixtures.

The IBANgen fixture manifest records what a test artifact contains, which registry snapshot and schemas it used, and how to verify that a replay has not drifted. The schema is open; hosted history, private artifacts and signing remain controlled workflows.

Open the workflow Read API docs
Scope: Synthetic and sandbox-only. This page documents QA and integration workflows; it does not claim live account verification or production payment execution.

Use it in three steps

1. Compile

Turn a set of generated or protocol fixtures into one replayable manifest.

Explore compile →

2. Verify

Recompute the canonical hash in CI and fail when the artifact or source metadata drifts.

Explore verify →

3. Hand off

Share a compact manifest with a bug report, release, pilot or design partner without sharing private account data.

Explore hand off →

Sources and freshness

Manifest specification

Open the documented source or runtime contract before relying on this workflow.

View source →Page evidence checked 2026-08-20

Questions teams ask

Does a manifest grant rights to redistribute source data?

No. Source, derived-data and export rights remain source-specific. The manifest only records the licence reference supplied by the producer.

What makes a fixture replayable?

A stable fixture id, seed, target context, registry snapshot, schema metadata and artifact hash let a CI or review workflow compare the same contract over time.

Can manifests contain real personal or account data?

They should not. IBANgen marks hosted artifacts synthetic-only and users must keep real personal or account data outside the fixture workflow.

Availability and source coverage are bounded by the current registry, fixture catalog and plan entitlements. If a target is not matched, IBANgen reports that state instead of inventing authoritative coverage.