Rhindon Cyber logo
    Support & Documentation
    Contact Support

    Portable Continuity Badge Specification

    An organization that has been sealing evidence in RAIC for months or years holds a fact that its competitors cannot manufacture retroactively. The portable continuity badge publishes that fact — and only that fact — so a prospect, an insurer, or an auditor can read it from your own website and follow it back to RAIC's public verification surface without a RAIC account. This page is the contract: what the badge asserts, what it deliberately withholds, and how to consume it.

    Discovery

    The badge contract is discoverable at a stable, cacheable path. Fetch /.well-known/raic-continuity to learn the current spec version, the signal endpoint, the badge endpoint, and the public verification endpoint. Take every URL from that descriptor rather than hardcoding paths, so a future revision cannot break your integration.

    • Descriptor: /.well-known/raic-continuity
    • Signal (JSON): /api/public/raic-continuity?slug=<opaque-slug>
    • Badge (SVG): /api/public/raic-continuity?slug=<opaque-slug>&format=svg
    • Verification: /api/public/verify-evidence
    • Current badge spec version: 1.0

    Identification is by opaque slug only

    A badge is addressed by the same opaque slug that addresses the organization's public Trust Portal. The endpoint never accepts an organization identifier from the caller: it resolves the slug to a portal row, requires that the portal is published, and reads the organization from that row. An unknown slug and an unpublished portal are indistinguishable in the response — both return 404. Withdrawing the Trust Portal withdraws the badge in the same action.

    What the signal asserts

    sealedDays
    Count of distinct days for which a day root was sealed.
    coveragePct
    Sealed days as a percentage of calendar days in the covered window.
    longestUnbrokenDays
    Longest run of consecutive sealed days.
    tenureDays / tenureYears
    Length of the covered window; whole years of tenure.
    milestoneYears / markerDays
    Highest earned continuity milestone (1, 3, 5 years) or sub-year marker (30, 90, 180 days).
    certified / certificateHashPrefix
    Whether a signed continuity certificate exists, and the first 16 hex characters of its hash so it can be matched offline.
    specVersion / signingKeyFingerprint
    Which published verifier specification text and which evidence signing key govern the signal.

    What the signal withholds, by construction

    The badge is produced by the same single redaction function that produces the Trust Portal continuity block and the partner fleet rows. There is no second serializer to keep in step, so the withheld set below cannot drift apart between surfaces.

    • Gap dates — which specific days were not sealed is tenant-internal.
    • Ledger volumes — entry counts per day or in total are never published.
    • Record contents — no governance record, actor, artifact, or decision text appears.
    • Tenant identifiers — no organization id, name, or domain is returned.
    • Exact first-seal date — only the length of the window is published.

    Embedding the badge

    The badge is a deterministic SVG: the same signal always renders byte-identically, so it caches well and diffs cleanly. Responses carry a 15-minute cache lifetime. Embed it with a plain anchor and image so it degrades to a link if images are blocked. Copy the ready-made snippet from Trust Portal settings, which fills in your slug for you.

    • Anchor target: https://app.rhindoncyber.com/support/continuity-badge
    • Image source: https://app.rhindoncyber.com/api/public/raic-continuity?slug=YOUR-SLUG&format=svg
    • Set height=20 and give the image descriptive alt text.

    Verifying rather than trusting the badge

    The badge is a claim; the verification endpoint is the check. Take the certificate hash prefix from the signal, obtain the full continuity certificate or audit pack from the organization, and confirm the hash and signature against /api/public/verify-evidence — or offline with the bundled independent verifier. The Evidence Verifier Specification governs the hashing scheme, the signature format, and the offline procedure; the badge adds no new cryptography of its own.

    Versioning

    The badge spec version in the descriptor changes only when the response shape changes. Fields are added, never repurposed: a consumer that ignores unknown fields keeps working across revisions. A field is never removed without a version increment and a deprecation note on this page.