Test the handoffs.
Keep the evidence.
A common interface gives independently built systems a place to meet. A reproducible test shows what happens when they actually do.
A laboratory for the connected application
The Transaction Processing Network Interoperability Laboratory (TPNIL) connects versioned requirements, exact software artifacts, controlled environments and inspectable outcomes. It gives builders a practical route from a compatibility promise to a named, repeatable test.
ITCVE-1 is the first Integrated Testing and Conformance Validation Environment. It defines component roles and their connections. An ISI—Interoperability and Standardization Initiative—defines the behavior to evaluate. A SUT, or System Under Test, is the exact implementation occupying a selected role.
Follow a transaction through the system
- Application ↔ walletBRC-100 requests, permissions, transaction creation and wallet records.
- Broadcaster → processorA submission service such as the pinned Broadcaster reference passes transactions to Teranode.
- Headers + proofsChainTracks tracks headers; Merkle Service supplies transaction-bound inclusion paths.
- Storage + overlays + contentWallet records, topic admission, lookup, synchronization and retrievable content complete the workflow.
This is a role map. A component can be under test in one run and a pinned supporting dependency in another. Substitution requires the declared interface, artifact admission and a qualified execution path.
Four programs, different questions
| Program | Question | Current boundary |
|---|---|---|
| ISI-1 | Can the connected application stack complete its workflow? | Reference and joined transaction-service qualifications retained; complete browser-app/external-wallet SUT run pending. |
| ISI-2 | Can overlays submit, look up and synchronize the expected topical state? | Draft vectors; external overlay qualification pending. |
| ISI-3 | Can wallet records synchronize through a multi-remote wallet into replacement storage? | Draft contract; HTTP driver and state oracle pending. |
| ISI-4 | Can a production wallet support the declared application workflow? | Executable drivers and the first retained experimental wallet result; broader coverage remains incomplete. |
Use the profile that matches the claim
ISI-1 through ISI-3 select ITCVE-1 version 0.1.0, the integrated regtest design. ISI-4 selects version 1.0.0: production wallet artifacts in mainnet configuration, connected to controlled services and isolated fixtures through supported settings.
The latter does not establish public-mainnet acceptance or economic value. A clean guest, pinned dependencies, reset procedure and observed service routes are part of the test boundary.
Read outcomes as engineering evidence
Yours Wallet 5.1.0 has two retained runs with matching semantic outcomes: V001–V004 pass, V005–V006 fail and V007–V008 are blocked. Metanet Explorer has four Android observations reaching ToDo transaction submission but an unresolved wallet-response/task-visibility boundary. BSV Browser has source-candidate engineering evidence; BSV Desktop has native intake and bridge qualification with integration prerequisites remaining.
A failure is a useful finding when execution and evidence are sound. Passing a subset does not establish complete BRC-100 conformance, universal wallet compatibility, recovery or adoption.
Use the result-reading checklist → · BRC-100 testing entry point →