The data appears.
Business rules and certification data — no support call needed. Apparet, Latin for "it is evident".
Why this exists
In B2B integrations, finding out what data lives in the certification environment and why a record was rejected usually ends in a phone call to support. Apparet demonstrates the alternative: a portal where rules are searchable, the database is browsable, and every result explains itself.
Everything here is a demo built on 100% fictitious data from the imaginary Banco Exemplo S.A. and its TIF scheme (Fictitious Instant Transfer). No real system is ever queried.
Business rules fictitious
Query sandbox fictitious data
Integration simulator simulated
Build a call, fire it against the sample data and see the request and response just like in certification. Trigger the error cases (RN-xxx) and learn what would break — before you submit for real. Everything here is simulated: no call ever leaves your browser for a real system.
Domain map fictitious
How it all connects — the 4 fictitious entities of Banco Exemplo S.A., their relationships, the rules that govern each, and the lifecycles. All derived from the same deterministic-engine source (zero invention) and clickable.
Ecosystem & journeys fictitious
Banco Exemplo S.A. doesn't live alone: it operates inside a payment scheme, alongside other institutions, a key directory, a settler and a supervisor. See who's who — and how each rule plays out end to end. All fictitious.
Who's who in the TIF scheme
At the center, the Fictitious Monetary Authority (AMF) operates two rails: the DCC (key directory) and the LTIF (settler). Left to right, the path a registration, a key or a transfer takes outward from Banco Exemplo. Hover or tap each actor to see its role and the rules in play.
Journeys of the rules
Three end-to-end paths. Each step points to the rule (RN) that governs it — hover or tap to see what it says.
How it works
What it is (and isn't)
Apparet is a demonstration of the farpa method applied to a real B2B integration pain: the pre-integration phase that still depends on phone calls. It is not a white-label product for sale, it does not query any real system, and it does not replace any provider's official documentation.
The rules of the game
1 · The engine is deterministic: sandbox queries are pre-modeled with validated filters — AI never computes a result. 2 · AI only explains, anchored to the rule's canonical text, and every generated answer carries the AI-derived seal. 3 · The data is obviously fictitious by design. 4 · AAA accessibility is non-negotiable (high contrast across all themes). 5 · First-party telemetry, cookieless, no personal data.
Simulate API calls
Beyond querying the database, you can build an API call and fire it against the fictitious data — seeing request and response just like in certification, including the errors (RN-012, RN-013…). Responses are deterministic and simulated: the address is fictitious (api.bancoexemplo.fic), no call ever leaves your browser, and the exported cURL is stamped as simulated (X-Farpa-Simulated). Key-lifecycle and transfer-flow diagrams help you understand the process behind each call.
Ask the rules (anchored chat)
The Rules tab has a chat that answers questions spanning multiple rules ("what's the difference between RN-012 and RN-013?", "why did my key disappear from the query?"). It is anchored: a deterministic engine retrieves the relevant rules and the AI answers only from them, citing the codes — if the question falls outside the 16 rules, it declines rather than inventing. It describes what the rule says; it doesn't advise conduct and isn't an official support channel. Every answer carries the AI-derived seal. On each rule's screen you can also ask a free-form question anchored to that single rule — same anchoring, refusal and seal.
Domain map
The Map tab shows how the 4 entities connect (customer → account → key/transfer), which rules govern each, and the lifecycles — all derived from the same engine source (relationships come from the schema fields, rules from the catalog itself · zero invention). Every node and rule is clickable and leads to the sandbox, the rule, or the chat.
Ecosystem and journeys
The Ecosystem tab steps back and shows Banco Exemplo S.A. inside a payment scheme: the key directory, the settler, the other institutions and the supervisor. It then draws three end-to-end journeys (register a key, send a transfer, open an account), with each step anchored to the rule (RN) that governs it. The actors and rails (AMF, DCC, LTIF) are made up: the illustration mirrors how instant-payment schemes are typically organized, but it does not represent Pix, any central bank or any real institution.
Where the fictitious rules come from
The 16 rules (RN-001 through RN-016) were invented to feel like real business rules of an instant-payment scheme — limits, key lifecycles, blocks — without reproducing any literal rule of an existing scheme.
Help us validate (external listening)
This product runs in internal-only-not-validated mode: it hasn't been validated with real integrators yet. If you integrate systems and this pain is yours, tell us how the concept would apply to your context — including the questions the portal did not answer: