For regulated teams

The UI layer that leaves your compliance scope.

Auditable, self-hosted, no-eval. Blueprint runs inside your boundary — no data leaves, nothing executes that you didn’t compile, and every screen is a diff a reviewer can read.

No evalSelf-hostedNo data egressOpen source

Most UI tools become a vendor you audit. Blueprint is a library you run.

Every hosted builder is another third party in scope — another SOC 2 to collect, another processor to justify, another entry that can change on someone else’s server. A library that runs in your own environment isn’t in your scope at all. That’s not a smaller audit. It’s one fewer thing to audit.

Coverage

Pick the obligation you’re graded on.

Six of the constraints regulated teams live with — and the architectural property in Blueprint that answers each. Not a certificate; a design decision.

Guarantee PCI DSS 4.0 · §6.4.3 / §11.6.1

The payment page ships with a short script inventory — and zero eval.

Since March 2025 every script on a payment page must be inventoried, justified, and tamper-monitored. Blueprint generates nothing from strings, so the inventory is short, the CSP stays strict, and the payload can’t change without a deploy you control.

eval() = 0inline scripts = 0CSP strict · passes
PCI SSC — payment-page security (verified)Full PCI detail
The evidence

What an auditor sees: a diff, not a promise.

A change to a regulated screen is a reviewable diff. The payload it produces carries no eval and an inventory your scanner can check.

contracts/checkout.json · PR #482 · reviewed by @compliance
{ "type": "form", "id": "checkout",
  "fields": [
    { "type": "input", "label": "Card number" },
    { "type": "button", "label": "Pay" }
    { "type": "checkbox",
      "label": "I authorize this payment", "required": true },
    { "type": "button", "label": "Pay" }
  ] }

The whole client footprint

0lines of eval, inline, or injected script

Script inventory · /checkout

  • Contract signed · v14
  • Runtime-injected 0
  • CSP strict
Honest by default

What we claim — and what we don’t.

What we claim Verifiable

  • No eval in the payload — nothing generated from strings. Watch it under a strict CSP
  • No data egress — self-hosted, runs in your environment.
  • The runtime is open source (AGPL) — your team reads every line.
  • The contract is versioned, diffable, CSP-clean.

What we don’t claim On purpose

  • We’re not SOC 2 / PCI / ISO certified — a library you run isn’t a SaaS in your scope.
  • We don’t process or store your data — nothing of yours for us to lose.
  • We don’t make you compliant — we make your compliance provable.
For your security review

The questions your compliance team will ask.

Are you SOC 2 Type II certified?

Blueprint is a self-hosted, open-source runtime — not a SaaS that holds your data — so there’s no Blueprint environment inside your audit scope to certify. The code is open for your team to review, and we’re glad to walk your security engineers through the architecture.

Do we need a BAA?

Blueprint never receives your data, so there’s typically no processor relationship to cover with a Business Associate Agreement. Confirm the specifics with your counsel for your deployment.

Can we run it air-gapped?

Yes. The runtime is a thin library with no phone-home — it runs fully offline, inside your own network.

Who can change a screen in production?

Whoever your review process allows. Every screen is a contract in version control, so a change is a diff that’s reviewed and signed off like any other code change — not an edit that takes effect on a vendor’s server.

Is the payload safe on a payment page?

There’s no eval and no code-from-strings. The payload is inventoried and CSP-clean — exactly what PCI DSS §6.4.3 and §11.6.1 ask you to demonstrate for scripts on a payment page.

Bring us your hardest audit

The screen becomes a diff. The vendor leaves your scope. That’s the whole pitch.