FAEI.DEV / OPERATIONAL VERIFIER WORKBENCH
This site follows a financial instruction from request to destination acceptance. Each stage names who can authorize it, what is actually deployed, and where the evidence stops.
Current state, not a system-integration diagram.
The break is material: Suwappu policy records are not settlement proofs. Lattice attestations do not authorize Suwappu execution. No deployed FAEI corridor currently closes the destination stage.
Authority, deployment, boundary, and source are separate fields. A green build or a testnet contract cannot fill in the others.
| Stage | Authority | Deployed state | Boundary | Primary source |
|---|---|---|---|---|
| Request | Human or registered software agent | Suwappu live product; open beta | An accepted request is not permission to execute. | Live product · Apache-2.0 source |
| Policy | Organization rules, wallet rules, and human approver | Control machinery in source and managed paths | A caller holding its own key can sign outside Suwappu's hard boundary. Universal enforcement is not claimed. | Architecture · Capability manifest |
| Execution | The applicable wallet signer and destination protocols | Live interfaces over current liquidity and interoperability providers | Custody and enforcement vary by signing path. The application audit chain is not a settlement proof. | Execution dossier · Product documentation |
| Attestation | Lattice commitment, committee, and corridor machinery | Public pre-GA stack with testnet contracts | The current bridge fast path is simulated; the optimistic path is administrative or arbitral. This is not proof-secured production settlement. | Public repository · Bridge trust model |
| Destination | A verifier contract under explicit finality and upgrade rules | No FAEI destination-verified corridor deployed | A signer, relay, administrator, or arbiter must not decide whether invalid evidence becomes valid. | Architecture brief · Acceptance specification |
| Portfolio join | None | Not integrated | The repositories, deployments, and runtime paths remain separate. | Suwappu source · Lattice source |
The first corridor experiment should run beside an existing rail and be judged by what the destination refuses, not by a launch announcement.
Capture
Use a Suwappu stablecoin or treasury route with observable demand. Record current latency, cost, failures, recovery work, and trust dependencies before adding new machinery.
Explicit source finality and one narrow destination action.
Shadow
Build an LTP package through a controlled gateway and deliver it to a candidate verifier while the incumbent route remains authoritative.
Proof cost, latency, liveness, data recovery, and operator intervention.
Reject
The destination must locally reject malformed, replayed, premature, mismatched, and otherwise invalid evidence without asking an operator what to believe.
Independent review, constrained upgrades, explicit reorg behavior, and a separately reviewed application contract.
The commercial claim should stop at the same boundary as the technical claim.
Suwappu source includes subscriptions, execution fees, prepaid credits, per-call metering, referrals, organization controls, and support paths. It does not establish revenue, volume, retention, or market share.
Gateway deployment, evidence packaging, verifier prototypes, and corridor measurement can be scoped as paid work in testnet or shadow environments.
Proof receipts, settlement-status APIs, monitoring, incident response, verifier integration, and application-specific invariant work become credible only after review and operating evidence.
Lattice defers a native token and explores stablecoin-denominated bonds; that mapping is not production code. Suwappu's separate testnet SUWP contracts do not form a unified portfolio economy.
Stablecoin bonds would import issuer, freeze, depeg, custody, compliance, concentration, and capital-cost risk. Public code and testnet contracts are inputs to diligence, not substitutes for it.
The workbench uses the June 2026 Bridgeless Bridge brief as the destination-acceptance rule, then checks product and protocol claims against the current public repositories.