Open format, closed service

The constitution#

Specification v0.2 opens with a split it calls the constitution. Quoted, not paraphrased:

OPEN (published, versioned, reproducible by anyone): Grant semantics · Proof format · protocol verification rules · Receipt format · Outcome Attestation format · portable identity model.
DELEGUS (the service): issuer trust · live verification (replay, revocation freshness) · evidence preservation · decision signing · adapter network · outcome graph · risk models · economic assurance.

Everything a receipt means is on the open side. Everything that requires someone to be on duty — knowing which issuers are real, remembering which proofs of grant have been seen, keeping the evidence, signing — is on the service side. The rule that ties them together is the fifth design constraint:

Someone must be able to verify a Delegus artifact without calling Delegus.

What "open" concretely means here#

The specification is published, frozen, and versioned. v0.2 is the normative text. v0.3 runs in production as release candidate 1, and becomes normative once it's frozen after an external cryptographic review. It is served as the v0.2 specification and kept permanently under a versioned path. Changes after the freeze are numbered errata, each stating the sections it touches, what changed and why, or a new version. Two errata exist; both are on the errata page with their reasoning. Nothing is edited in place.

The rules are a document with a hash. In v0.2, the twenty protocol checks, in their fixed evaluation order, are the profile delegus-base-v1, served byte for byte. In v0.3 the profile is delegus-base-v3: P1 to P21 plus the dependency checks D1 to D7. Its SHA-256 appears in every receipt as protocol.profile_hash. You are never verifying against "the rules"; you are verifying against those bytes, and the receipt says which.

The formats are standard. Grants are Verifiable Credentials signed as JWS. A proof of grant is the agent's per-request Ed25519 signature, bound to one grant, one recipient, one canonicalized action and one moment. Receipts are compact JWS. Canonicalisation is RFC 8785. Identity is did:web for organizations and did:key for agents — DNS, HTTPS and Ed25519, nothing else. The specification's first design constraint is that an ordinary backend engineer can implement the protocol layer with a standard JOSE library, and that constraint was enforced on the reference engine, which has no runtime dependencies.

The reference engine and SDK are Apache-2.0. @delegus/core is the pure engine: it takes the artifacts, the evidence snapshots and the clock as inputs, performs no I/O, and returns the decision. @delegus/sdk wraps it with the client and the delegus CLI. Both carry the Apache License 2.0. Both are published on npm: @delegus/core and @delegus/sdk.

text

npm install @delegus/sdk

Conformance is a test suite, not a promise. The engine ships a conformance suite: fixed test keys, a fixed clock, and non-production identifiers; three ALLOW paths and one DENY vector for every reason code in the specification, plus sets for htu normalization, RFC 8785 canonicalization and jti format. Every vector is reproducible byte for byte on any platform — Ed25519 signing is deterministic and even the status-list gzip encoding is pinned to a fixed pure-JS encoder so the bytes never drift between zlib versions. A third-party implementation reproduces expected from input. Delegus does not claim conformance for anything that does not pass every required vector.

Every receipt is re-verifiable without Delegus. For a v0.2 receipt: given the receipt, the published receipt public key, and the four evidence artifacts the receipt names by hash, anyone re-runs the profile with the receipt's own signed evaluated_at as the clock and confirms the protocol result. In v0.3, a receipt's authenticity is public: anyone holding it can check it's genuine and unmodified. Re-deriving why it was decided is for its parties, who hold the openings and the disclosure package. This is covered in detail in the receipts post; the point here is that it is on the open side of the line, by design, and tested.

What "closed" concretely means, and why#

The service is proprietary and run by Delegus, and that is part of the design.

Issuer trust. Someone has to decide that did:web:acme.com really is Acme, that the domain proof happened, that a key reported compromised is not honored. That is a registry with a human process behind it, and it is an accountable party's job.

Liveness: replay and revocation. A proof of grant must be accepted exactly once, anywhere. A revocation, once acknowledged, must be seen by every later verification, anywhere. v0.2 makes both normative. Those are properties of a single coordinated service, not of a format; a federation of independent verifiers cannot promise either. The receipt's trust block records Delegus's attestation of these checks, and the spec is explicit that this block is not reproducible by design — you verify that Delegus Check signed it, not that you could have computed it.

Evidence preservation. Everything a receipt references stays retrievable by hash for seven years, as the specification requires. The production store is Backblaze B2 Object Lock in compliance mode: every receipt issued from 25 Sep is written there before the answer is returned, earlier receipts were copied in and checked by hash, and nobody, Delegus included, can delete or alter them inside the window. Preservation is an obligation someone has to carry for seven years; a protocol cannot carry it.

Signing. Receipt keys live in Google Cloud KMS and never leave it; the public halves are published in the DID document. Rotation adds a key and never removes one, so old receipts keep verifying. Only Delegus holds the private keys, and that is what "only Delegus can produce a fresh artifact" means in practice.

Why draw the line this way#

Three reasons.

Because verification has to outlive the vendor. A receipt for a purchase made in 2026 may be the deciding document in a dispute in 2031. If verifying it required Delegus's API to still exist, still be reachable, and still agree, the receipt would be a promise, not evidence. Putting the format, the rules and the re-verification procedure on the open side means the receipt stands on its own with a public key and four blobs.

Because "fail closed" and "deterministic" are only credible if you can check them. The specification says unknown, missing, ambiguous or unavailable inputs produce DENY, and that the same inputs and snapshots give the same result anywhere. Those are strong claims. The conformance suite is how they are made checkable rather than asserted, and it only works because the engine is a pure function you can run yourself.

Because the service's value is exactly what can't be open. Being on duty — knowing who is real, remembering every proof of grant, keeping every byte, signing with keys nobody else has — is what a relying party pays for. Giving the format away does not give that away. It makes it worth more, because every decision Delegus Check signs is one anyone can audit.

What this is not#

It is not a foundation, a consortium, or a chain. There is one specification, one accountable operator of the service, and one place the private keys are. It is not "open core" in the sense of a crippled free version: the open engine is the whole protocol layer, and it is the same code the service runs. And it is not a claim that the format will never change: it will, through numbered errata and a v0.3, in public, with every old receipt still verifying against the version that produced it.

The licensing is stated in the specification's own header, as non-normative metadata that changes no normative text, no profile document and no trust-configuration descriptor: the specification text is licensed under Creative Commons Attribution 4.0 International (CC BY 4.0); the reference engine @delegus/core, including its conformance vectors, and the SDK @delegus/sdk are licensed separately under Apache-2.0; the service is proprietary. Short form: specification text CC BY 4.0, reference engine and SDK Apache-2.0, service proprietary.

Under v0.3#

v0.3 (release candidate). v0.3 keeps this line and makes one distinction sharper: receipt authenticity is public; receipt reasoning is entitled. Anyone holding a v2 receipt checks, without calling Delegus, that it is authentic and unmodified. Checking what it pins (what the matched capability allowed, which earlier decisions it relied on, what those checks read) takes material that only the receipt's relying party and principal hold or can fetch. Once they have it, they reproduce the pinned values offline, with the receipt's own clock.

Open rules, private facts#

The rules stay open. The v0.3 checks (P1–P21 and the dependency checks D1–D7) are a published profile document, delegus-base-v3, whose hash appears in every v2 receipt as protocol.profile_hash. The byte framing of every commitment is in the specification, and the conformance set is designed to include known-answer vectors for each one, so anyone can check an implementation computes the same bytes.

What v0.3 keeps private are the facts of a particular decision. The specification states five privacy principles (§0.1):

Being able to verify is not being able to find. Verifying a receipt, a dependency or a transaction handle never lets anyone find, list or fetch other receipts or evidence.
Evidence reveals no more than the claim needs. A receipt carries hashes and commitments wherever the plaintext is not needed to check it.
Authenticity is public; reasoning is entitled.
A receipt may show that it depended on earlier decisions. It does not, by itself, give access to them.
Transaction handles give correlation, not discovery.

One limit is stated, not hidden: Delegus Check issues and evaluates every receipt in a deal, so Delegus itself can link them. Handles and commitments limit what outsiders can link, not what Delegus can.

The constitution under v0.3#

The v0.3 release candidate keeps this split unchanged. Its dependency checks D1–D7 are on the open side (they are in the published profile); whether two dependencies belong to the same deal (D5) is Delegus's attestation, like the trust block, because the internal transaction is never disclosed.