OCALA 1.0.0TRUST INFRASTRUCTURE

“Verified” is not
a data model.

Ocala decomposes credential trust into issuer, signer authority, key epoch, lifecycle, provenance and exact proof—so systems can explain what they actually know.

See it in CrewCloud Decode the model

01 / TRUST MODEL

A signature proves
one thing.

Everything else needs its own evidence.

INTEGRITYWas this payload signed by the referenced key?cryptographic proof

ISSUERWhich organization does the credential represent?registry + schema

AUTHORITYWas this signer allowed to issue it at that moment?authorization snapshot

LIFECYCLEActive, suspended, revoked, superseded or expired?current state

PROVENANCEWhere did the assertion actually come from?source classification

02 / CREDENTIAL LIFECYCLE

Immutable proof.
Mutable status.

ISSUEDcanonical payload + proof fixed

ACTIVEcurrent lifecycle valid

SUSPENDEDtemporarily not current

REVOKEDexplicit invalidation

SUPERSEDEDreplacement linked

SELF PROVIDEDSOURCE CONFIRMEDISSUER SIGNEDAUTHORITY ISSUED

03 / VERIFICATION

Never claim more
than the verifier knows.

Offline proof can establish signature integrity while remaining honest that lifecycle status may have changed since the last sync.

Credential proofoffline verification

LOCAL

✓

Signature verifiedcanonical payload matches key epoch 04

Current status unavailablelast lifecycle sync · 08:14 UTC

USED IN CREWCLOUD

04 / PRODUCT INTEGRATION

Trust technology stays
behind the product.

CrewCloud users see terms like Verified by issuer, Source confirmed, Active, Expired, Revoked and View proof. Ocala is the model that makes those words defensible.

CrewCloud + Ocala →

CREW QUALIFICATION