Open source · Apache 2.0

Open source. Deploy it yourself — or we'll run it with you.

CREED is Apache 2.0 licensed. Clone the repository, run the whole system from one Docker container or build it from source, and verify every result offline. If you'd rather have us deploy and manage a version for you, that's the other path — same software, operated together.

Browse the repository Talk to us about managed deployment

Licensed under the Apache License, Version 2.0. You may use, modify, and distribute it under the terms in the repository's LICENSE. No license fees, no seat limits, no call-home.

How it works

Four layers, with hard boundaries between them.

Extraction turns bytes into claims
Every file in a binder is detected from its bytes — never from a declared type — and dispatched to a deterministic extractor. Supported inputs: creed.claims.v1, ACTA assessment / POA&M / results JSON, CycloneDX 1.5 and SPDX 2.3 SBOMs, and ACTA+ authorization binder ZIPs. Same bytes, same claims, on every machine.
Modeling builds one causal structure
Each binder becomes exactly one deterministic event structure: a root event, one artifact event per file, one claim event per claim, and one coverage event per requirement at least one claim binds to. Every identifier is derived from content and causes, so byte-identical artifacts get identical identifiers in any binder. The structure's canonical digest is the ingestion digest.
Evaluation produces witnesses, not verdicts
The requirement set compiles to a constraint set and is evaluated against the structure. Every passing requirement carries a whole-match witness; every failing one carries a violation. Waivers sit on top as a separate overlay, so the underlying finding stays visible. The output is a canonical evaluation artifact with its own digest. CREED never grants, denies, or recommends a decision — it produces evidence; the AO decides.
Replay and drift keep it honest
Any ingestion rebuilds from its record and content-addressed artifacts; any evaluation re-runs from the stored artifact. A digest that differs is an explicit replay_mismatch. Every resubmission is compared against the last decided binder and the prior submission — artifact, claim, extractor, and coverage deltas, plus the untouched list.

One statically linked binary. Storage is a directory tree with atomic writes and content-addressed objects — no database, no outbound network calls. Full specification and design record live in the repository alongside the code.

How to run it

Two supported paths. Pick the one that matches your machine.

Path A · Recommended

Easy Deploy: one Docker container

One image runs everything — the HTTPS submission and oversight API, the embedded web interface at /, and the offline validator. Storage is a directory tree under /data. About five minutes to a first health check.

docker build -t creed:easy .
cp deploy/docker/roster.example.json ./roster.json
docker volume create creed-data
docker run --rm -p 8443:8443 \
  -v creed-data:/data \
  -v ./roster.json:/config/roster.json:ro \
  -e CREED_GENERATE_SELF_SIGNED=true \
  --name creed creed:easy
curl -sk https://127.0.0.1:8443/v1/health

The self-signed certificate is for evaluation only. For production, mount your environment CA's certificate and key and put a fronting proxy (CAC/PIV or equivalent) in front of port 8443 — the proxy must strip any inbound X-Creed-* headers and set the identity itself. Full operator manual: docs/deployment/easy-deploy.md in the repo.

Path B · From source

Build the Go binary yourself

Requires Go 1.22 or newer. The only dependency is fetched from the Go module proxy — no CGO, no external services. The binary is statically linked, so for a disconnected machine, build on a connected one and copy it over.

git clone https://github.com/Beautiful-Majestic-Dolphin/creed.git
cd creed
go build ./...
go test -short ./...
go build -o creed-server ./cmd/creed-server
go build -o creed-validate ./cmd/creed-validate

Start the server with a roster file and TLS pair: ./creed-server -root /var/lib/creed -roster roster.json -tls-cert cert.pem -tls-key key.pem -listen :8443. The server refuses to start without TLS unless it is explicitly run in development mode.

How to use it

From requirement set to decision, in five moves.

1 · Publish a requirement set

Compose from the shipped definitions — NIST SP 800-53 Rev 5, SP 800-171 Rev 2 and Rev 3, CMMC 2.0 Levels 1 and 2 — or author your own JSON. A published set is immutable and identified by its digest; systems bind to one set, and rebinding is an explicit recorded event.

2 · Prepare a binder directory

A binder is a directory with a binder.json manifest and one artifact file per entry — claims files, ACTA exports, SBOMs, ACTA+ binder ZIPs, freely mixed. The four binders under testdata/corpus/ are complete working examples.

3 · Validate offline before submitting

The offline validator reproduces the server byte for byte. Binders arrive already passing — or arrive with the submitter knowing exactly what is unmet.

creed-validate -binder testdata/corpus/basic \
  -reqset testdata/corpus/reqset.json \
  -as-of 2026-09-06 -out ./out

4 · Submit through the page or the API

The server assigns the occurrence number, extracts, checks classification against the system's authorized level, evaluates, and answers with the digests, the unmet requirements, waiver-dependent requirements, and anything unattached or mismatched. Over-classified binders are refused — nothing is stored, and a spillage record is written.

5 · Review the delta, record the decision

Drift names what a resubmission changed so review scopes to the delta. Returns render from a fixed template — the requirement, what was found, what would satisfy it, the digests to reproduce it. Decisions are returned, accepted_for_review, and risk_decision_recorded — the last by the AO only. Compare any two submissions offline with creed-drift.

Managed deployment

Rather have us deploy and manage it for you?

Self-hosting is yours to do — the license guarantees that. But running authorization infrastructure in your own environment still takes work: hardened hosting, TLS and proxy integration with your identity system, roster provisioning, upgrades against your requirement sets, backups with a retention story, and someone to call when an evaluation disagrees with a submitter.

We deploy a version for you, in your environment or ours, keep it current with upstream, and manage it day to day — while your evidence stays reproducible against the open source you could always run yourself. Same bytes, same result, whoever operates the server.

Ask about managed deployment

Tell us your environment and timeline — we respond within two business days.

Keep going in the repository: docs/README.md (concepts, guides, references), deploy/README.md (deploy cheat sheet), and the codebase itself. Every failure carries a stable code — unsupported_input, manifest_mismatch, classification_exceeds_system, waiver_unauthorized, replay_mismatch — and nothing is ever stored partially.