Back to the workflow

    How It Works

    Govern

    Approvers sign releases under role‑at‑time‑of‑action RBAC. ApproverReleaseSigned closes the chain for that version, ReleasePromoted records each environment promotion, and CI/CD pulls the signed spec — no untracked path to production.

    Govern is where the two-component electronic signature requirement of 21 CFR Part 11 §11.200 is enforced by the data structure, not by application discipline. A production release requires a Contributor draft signature (`DraftSaved` + actor signature) plus an Approver release signature (`ApproverReleaseSigned`). Neither signature can be back-dated — both ULIDs encode their millisecond timestamps in their primary keys.

    An `ApproverReleaseSigned` entry carries the mapping ULID, the prior `MappingRevised` ULID it is signing off, the Approver's role at time of action, the canonical mapping payload hash, and the SHA-256 of the chain immediately before the signature. A reviewer who arrives later can replay the chain up to the signature and verify both the content and the chain head — the signature is over both, not just the content.

    Promotion to an environment writes `ReleasePromoted` carrying the source `ApproverReleaseSigned` ULID, the target environment identifier (`dev`, `staging`, `prod-us-east-1`), and the actor's role at time of action. CI/CD (see CI/CD Pipelines) pulls the pinned mapping ULID for the target environment from the API; a deployment whose committed artifact does not hash-match the pin is rejected at the API layer before the build proceeds.

    Quality gates run server-side. Each gate evaluation writes `QualityGateEvaluated` with pass/fail and the rule identifier — so a SOX §404 walkthrough can reconstruct why a specific promotion was blocked six months later, not just that it was. A failed gate cannot be 'overridden' by a CI configuration; the override path requires an Approver to publish a new mapping version, which writes its own ledger entries.

    Quarterly attestation closes the loop under Compliance Officer review. Each cycle the Compliance Officer (a distinct role from the technical Administrator under the seven-role RBAC model) exports the ledger range, verifies the SHA-256 hash chain, and writes a signed attestation entry — itself a ledger row — covering the verified range. This satisfies HIPAA §164.308(a)(1)(ii)(D), 21 CFR Part 11 §11.10(j), EU GMP Annex 11 §9, GDPR Art. 30, FedRAMP AU-6, and ISO 27001 A.5.35 with one workflow.

    From the auditor's seat, the Govern phase is what they look at first. The full architecture — ULID primary keys, SHA-256 chain, role-at-time-of-action RBAC, two-component signatures — is summarized in the Magellan Audit Architecture brief and demonstrated against framework-specific framing on /audit (HIPAA + Part 11) and /audit/regulated-industries (SOX, GxP, GDPR, FedRAMP, ISO 27001).

    Audit ledger entries written by this capability

    Each action in this capability appends one of the following entry types to the ULID‑keyed, SHA‑256 hash‑chained audit ledger. A reviewer can replay the chain to reconstruct exactly what happened, when, and under which role.

    ApprovalRequestedApprovalGrantedApproverReleaseSignedReleasePromotedQualityGateEvaluatedVersionDeprecated
    Read the full Audit & Trust architecture

    See govern demonstrated against your data

    Pick a sample dataset or bring your own. We will walk the ledger from ingest through Approver release in a single working session.

    Request a demo

    Related across the platform

    Where this capability hands off — upstream adapters, downstream governance, and the underlying audit primitives.

    All How It Works