SovereignFoundry

Architecture

Your app, one contract, one system of record

There is exactly one door into the core, and it validates everything that comes through it. That constraint is the reason your front end can be anything you want.

The boundary

  your app (any stack, any UI)
        │  REST + bearer key, tenant resolved from the key
        ▼
  accept-contract  ── rejects anything unpriced, unpinned, unbalanced
        │
        ▼
  frozen core   rating · premium ledger · cash ledger · equity
                cancellation · cession · documents · e-sign · notices
        │
        ▼
  system of record  (immutable filing versions, stamped transactions)

Your app never writes core records — not a premium row, not a ledger entry, not a filing. That is not a limitation bolted on for external developers: our own staff workspace, agency portal and consumer flow go through the same contract. You are running on the same rails we run on.

What the contract rejects

  • ✕Premium that is not broken out by coverage.
  • ✕Anything not pinned to a filed, active filing version.
  • ✕A transaction with no term or effective date.
  • ✕A treaty whose participant shares do not reconcile, or whose periods gap or overlap.
  • ✕An amount owed supplied by the client instead of computed from the policy's own schedule.

An unvalidated input is never booked. You get a structured error with a reason instead of a record you would have to unwind later.

The sequence

  1. 01

    Session

    You open a session with your key. The core resolves your licensee and the filing version effective today, and hands back the constraints your UI should render.

  2. 02

    Quote

    You post answers. The core rates through the filed path, stores a real quote number, and returns premium by coverage for each term with a single-use bind token.

  3. 03

    Application

    You stage applicant, driver and vehicle detail. Sensitive identifiers are encrypted at rest and read back masked.

  4. 04

    Attest and sign

    Required statements and forms come from the forms library by effective date. Signing is inline or sent to the buyer, and the evidence record is kept in the core.

  5. 05

    Bind

    One call issues the term, coverages, charges, earning schedule, cash entry and documents, and returns the policy number.

  6. 06

    React

    Signed webhooks tell your app what happened — including events raised by staff, agency or nightly processes, not just your own calls.

Config, not forks

Rate values, eligibility and cancellation triggers, pay plans, forms, signature gating and treaty definitions are yours to configure. The arithmetic underneath them — earning method, cancellation math, cession settlement — stays in the core so every tenant reconciles the same way. A mechanic the core does not know is a scoped engagement, not a silent fork.

DocsCustom work