OFN Receipts
Current integration boundary — 2026-10-17 [D]. OFN is a separately
owned economic receipt standard and issuance surface. This page describes
Skyzai's proposed integration across its product capabilities and two planned
app packages, Skyzai Personal and Skyzai Work. It is not a Skyzai product,
authority, regulated audit, or evidence of a live protocol.
Product-shaped or commercial language in linked historical sources does not
override this classification; route names do not prove deployment.
Status: pre-launch. This page describes target design; this document does not establish a deployed service.
Scope: proposed OFN economic receipt integration for Skyzai's product capabilities and app packages — not a Skyzai SKU or authority source. See The Product Family.
Surface: ofn.app / OFN SDK surfaces (receipt-native substrate)
Status: PLACEHOLDER CANON
Evidence tier: [C] for this public wiki page until linked to the canonical
OFN source and accepted external integration receipts.
What OFN Receipts Is
OFN specifies an economic receipt payload for a recorded commercial event: parties, order and payment references, exact amounts, payment rail, settlement state, and named tax, refund and remedy responsibilities. Skyzai proposes to connect that payload to a wider typed evidence trail. An API usage record, event check-in, personal vault record or settlement badge is not automatically an issued OFN economic receipt; each needs its own source, scope and type.
The role of this page is routing clarity. The source audit found an inactive
Flutter receipt-demo upload and synthetic local receipt records, not accepted
OFN issuance, settlement or export in a live Skyzai journey. OFN's own issuer
and integration gates remain separate from this .org wiki.
Required Boundary
- Receipts are evidence records, not legal advice.
- A stored receipt is not automatically a regulated audit, tax filing, or court-enforceable agreement.
- OFN economic payloads must come from an authorised OFN issuer or accepted integration; a locally fabricated JSON example is not issuance or settlement.
- Consequential action must cross the authorization membrane first: a Natural Person authorizes their own typed private act; a Legal Person acts through lawful external authority and required executors; a public-DAV consequence requires a complete exact-consequence receipt bound by the signer(s) required by applicable law, the entity's governing instrument, or a valid competent mandate. PRISM records and verifies only.
- Receipt publication, replay, export, and anchoring remain deployment-gated until the exact runtime and counterparty integration are verified.
Relation to Product Surfaces
| Surface | Proposed relationship to OFN or the wider evidence trail |
|---|---|
| API Pay | Usage evidence can reference an economic receipt if an authorised issuer records a real payment; usage alone is not OFN issuance. |
| Personal Receipts | User-controlled vaulting and export of records within their actual types and rights. |
| Pay POS | A real point-of-sale payment could produce an economic receipt after settlement evidence is supplied. |
| Events | Invite, RSVP, attendance and check-in are distinct non-economic records; ticket payment requires separate economic evidence. |
| DEX Settlement Badges | A badge displays evidence state; it is not settlement or an issued economic receipt. |
Proof Gates
This page graduates from placeholder to active technical canon only when:
- The separately owned OFN source, schema and issuer responsibility are linked and accepted for the exact integration.
- An authorised issuer can emit an economic receipt with required source and settlement fields; a Skyzai surface can verify its type and provenance without inventing missing facts.
- Replay and export work for at least one accepted product journey, with a pinned test receipt and human-readable verification record.
- The claim-control page distinguishes design, synthetic local proof, accepted integration and any independently verified live operation.