-
Notifications
You must be signed in to change notification settings - Fork 0
Trust and Provenance
Rather than an aftermarket addition it is the substrate. This holds in the current 0.2.0 release, built on the v3 (calibration-free) substrate: the trust layer sits above the store's quantization format and is unaffected by it, so the guarantees below are identical regardless of how a frame's embedding is encoded on disk. Every store carries an attestation of its creator from genesis. When the application supplies a writer identity — the standard configuration for Commercial and Enterprise deployments, every committed record additionally carries a signature over its content, attributing it to that writer's key. Two independent facts are recorded and separately verifiable: the license under which the store was created (attested by SERAPH's licensor) and the writer who signed each record (a key the customer holds and SERAPH never sees). Internal tamper-evidence is thereby extended from "the chain is internally consistent" to "every record is provably attributable to the writer who created it, and that attribution cannot be silently transferred or forged, not even by the licensor."
SERAPH is distributed in three license tiers. The tier determines the security posture available to the operator:
| Tier | Secure mode | Writer attribution | Sealing | Full DSG substrate |
|---|---|---|---|---|
| Free | Non-secure stores only | No | No | Yes |
| Commercial | Available — application supplies the writer key | Per-record Ed25519 signatures (app-held key) | Yes | Yes |
| Enterprise | Available — application/PKI writer identity | Per-record Ed25519 / RSA-3072 / ECDSA-P384 (app/PKI key) + Gov mode | Yes | Yes |
The tier distinction is enforced structurally, not by a configuration flag the operator can flip. The license token is secret-free, it contains no signing key of any kind. Writer identity is supplied separately by the application through the engine's identity interface (an in-process Ed25519 key for Commercial, or an X.509 / PKCS#11 provider for Gov/Enterprise); SERAPH only ever calls the provider to sign and records its public key in the store, it never sources, ships, or holds the writer's private key. A store becomes secure when the license tier permits it and the application supplies a writer identity: supplying one engages per-record signing, omitting one yields a non-secure (still tamper-evident) store. The arrangement is deliberate, because the writer key lives only in the customer's deployment, authorship is evidence-grade: provable even against the licensor, who cannot fabricate it.
All three tiers receive the full DSG substrate: emergent similarity, declared relationships, eigenframe promotion, traversal, consolidation, contradiction detection, and watermark-chain integrity. A Free-tier store is a fully functional SERAPH store; it simply lacks writer attribution and the cryptographic features that depend on it. Free-tier installations can also read and verify any .sfg file, including sealed secure stores, verification requires only the writer's public key, which is recorded in the store's genesis attestation; no signing key and no contact with the licensor are needed.
When a store is created, its genesis record encodes the precise circumstances of its origin: the wall-clock time of creation, the embedding model in use, a hash of the configuration that governs the substrate's geometry, an optional external time anchor, the licensor-signed license attestation of the party who created it (customer UUID, tier, validity), and — when a writer identity is supplied — the writer's public key and signing algorithm, which become the anchor against which every per-record signature is later verified. These are canonically serialized and folded into the genesis watermark, becoming the cryptographic anchor from which the rest of the chain extends. Any subsequent attempt to claim a different creator, configuration, writer key, or moment of origin invalidates the chain at its root.
In a secure store — a Commercial or Enterprise deployment that supplies a writer identity — every committed record carries an Ed25519 signature over the record's content commitment, verified against the writer public key anchored in the genesis attestation. Because that anchor is folded into the genesis watermark, writer identity is load-bearing rather than metadata adjacent to the chain: a store cannot be re-attributed to a different writer without breaking the chain at its root. A verifier replaying the chain produces a complete writer histogram: who contributed which records, in what order, and whether any record was written by a party other than the store's original creator. Cross-author activity is visible immediately. The cost of this attribution is small — under twenty microseconds of signature work per record, dwarfed by the embedding cost that already dominates the write path, and roughly three percent of typical per-record storage.
A store may be sealed when its content is final. Sealing appends a signed sentinel record and one-way refuses all further writes from the engine. The seal travels with the store as part of the chain itself, not as a sidecar file, so recipients of a sealed store can confirm at a glance that it was distributed as a finished artifact rather than handed off mid-edit. Records committed after a seal are visible as such in audit, and the substrate's secure mode refuses to produce them in the first place.
The chain's lower bound, the moment its content was first committed, can be cryptographically tied to a trusted external time source. SERAPH ships with two anchor backends: OpenTimestamps, which produces free Bitcoin-anchored proofs suitable for academic, research, and open-source use, and RFC 3161, which uses contracted Time Stamping Authorities and is the prevailing standard for enterprise, legal, and regulatory contexts. Periodic anchors of the chain tip, committed as records in the chain itself, provide upper bounds at the customer's chosen cadence. Combined, the result is a temporal lattice in which every record's existence time is cryptographically bounded from both directions — without external sidecar files, and without trust in the operator's local clock.
A single call returns a structured audit of any store: chain integrity, genesis reconstruction, operator identity signature, anchor validity, sealed status, writer histogram, cross-author write counts, and the signature validity of every individual record. Verifiers extract the writer's public key directly from the genesis attestation and validate every per-record signature without any out-of-band lookup. (The licensor's signature in genesis attests the license — customer UUID, tier, validity — not the writer key; the two are independent facts, which is precisely what makes authorship provable even against the licensor.) A third party receiving a sealed store can verify everything it claims using only the file and a standalone verification utility — no network connectivity, no contractual relationship, no acquisition of a license required.
As of the 0.2.0 release, Commercial and Enterprise SERAPH stores are cryptographically bound to the licensed deployment that produced them. Chains from authorized installations are inherently distinguishable from those of unauthorized installations — not as a form of copy protection but as substrate-level provenance that any third party can verify with the binary alone. For compliance-sensitive customers, this distinction represents real commercial value: the artifact defends its own origin without dependence on external trust. Free-tier stores carry genesis attestation and watermark-chain integrity but do not carry per-record writer signatures; the upgrade path from Free to Commercial adds per-record writer attribution — engaged when the application supplies a writer key — without requiring re-ingestion of existing content.
Any party in possession of a SERAPH store, including legitimate licensees other than the store's creator, leaves a cryptographic fingerprint on every record they commit. Adversarial appends to a received store, accidental cross-author writes, post-distribution tampering with content or declared relationships, and silent substitution of a creator's identity are all detected at verification time. None of these are theoretical: each is a real failure mode in distributed knowledge systems, and SERAPH addresses each at the substrate level.
What secure mode does not claim to prevent is the use of a forked engine that bypasses license validation entirely. Such a system can write any bytes it likes to a file, but the resulting artifact carries no valid signature against the licensor's trusted keys and is cryptographically distinguishable from a store produced by an authorized installation. This is the appropriate division of responsibility: cryptographic provenance defends against forgery, and contractual licensing defends against unauthorized use of the software itself.
The result is a knowledge base that answers, with cryptographic rigor, the question every serious knowledge system eventually faces:
What did we record, what did we claim about it, when did we record it, who recorded it, and can all of that be proven?
In prior versions this guarantee was specified and held in reserve, activated only by deployments that required it. As of the 0.2.0 release, the Commercial and Enterprise tiers unlock the full trust model: internal integrity and genesis attestation apply to every store automatically, and — once the application supplies a writer identity — per-record writer signatures, external time anchoring, and one-way sealing operate from the moment of store creation. The license gates the tier; the application supplies the writer key. Free-tier stores retain the watermark chain and genesis attestation — the append-only integrity guarantee — but do not carry per-record writer signatures or support sealing. For deployments in which a knowledge artifact must travel between organizations, the Commercial tier transforms verification from a matter of institutional trust to a matter of arithmetic.
For deployments requiring compartmented access control and per-operator accountability, the Enterprise tier extends this trust model further
Public overview of SERAPH's enterprise (Gov) mode. For deployments where classification, compartmentation, and per-operator accountability are requirements rather than preferences — intelligence, defense, law enforcement, and regulated enterprise.
SERAPH's enterprise tier extends the substrate's trust model from what was recorded and by whom to who was cleared to record it, at what classification, in which compartments — and whether all of that can be proven at the level of an individual record.
Gov mode is a distinct security posture fixed when a store is created. It is part of the substrate, not a layer bolted on top: a standard SERAPH engine will not open a Gov-mode store at all — only the enterprise engine can create or operate on one. The separation is architectural, not a configuration toggle.
A Gov-mode store carries three independent cryptographic trust chains, each answering a different question. They are orthogonal: compromising one does not weaken the others, and all three are checked together.
| Chain | Answers | Anchored by |
|---|---|---|
| Software license | Is this an authorized engine at the correct tier? | SERAPH licensor signature |
| Operator identity | Who wrote each record? | The customer's own PKI |
| Time anchor | When was it written? | RFC 3161 TSAs / OpenTimestamps |
A forged operator credential cannot invalidate the license chain; a lapsed license cannot erase signatures already committed; neither can move a record in time. Each chain stands on its own.
Every record in a Gov-mode store is attributed to the individual operator who committed it — not the software license, not a shared service account, but the specific person or system principal.
Operator credentials come from the customer's own PKI (typically an X.509 certificate). The customer's application validates the certificate against its trust anchors and derives the operator's clearance; SERAPH then signs each record with that operator's key and records enough to let any future verifier confirm authorship offline — no live certificate or directory lookup required.
Crucially, the private key never leaves the customer's control. SERAPH only ever asks the operator's provider to produce a signature; it never holds, ships, or stores a private key. The same model covers software keys and hardware-backed keys (smartcard / HSM / TPM via PKCS#11), with identical guarantees — the engine is indifferent to where the key lives.
| Algorithm | Standard | FIPS posture |
|---|---|---|
| RSA-3072 (PKCS#1 v1.5 / SHA-256) | FIPS 186-4 | FIPS-approved |
| ECDSA P-384 / SHA-384 | FIPS 186-4 | FIPS-approved |
| Ed25519 | RFC 8032 | Supported (not FIPS-approved in most agency guidance) |
| ML-DSA-87 (post-quantum) | FIPS 204 | On the roadmap |
Different operators may use different algorithms within the same store; verification selects the right one automatically.
Every record carries its own classification level, compartments, dissemination controls, and special-access markings. These are not labels stored beside the data — they are folded into the record's tamper-evident cryptographic seal, the same seal that chains each record to the one before it.
The consequence is decisive: a classification cannot be silently changed. Altering a record's marking — downgrading TOP SECRET//SI//TK to SECRET, for example — breaks the cryptographic chain at exactly that record and is detected at verification. Classification integrity is not a matter of policy or trust in the operator; it is enforced by the same mechanism that protects the content itself.
A Gov-mode store enforces Bell-LaPadula mandatory access control inside the engine — not as a check the integrating application is trusted to remember to call. The engine refuses a disallowed operation before any data crosses the API boundary.
- Read-down. An operator sees only records at or below their clearance, and only in compartments they hold. This holds on every retrieval path — direct lookup, similarity search, and graph traversal alike. There is no path that returns a record an operator is not cleared for.
- Write control. An operator cannot record above their clearance.
- Compartments and special-access programs are enforced independently of classification level: holding TOP SECRET does not grant a compartment the operator has not been read into.
Access is decided by the standard lattice dominance rule — a clearance must meet or exceed the record's level and hold every compartment, special-access marking, and dissemination caveat the record carries.
An authorized auditor can verify an entire store — chain integrity, classification distribution, and operator attribution across every record — without being able to read content they are not cleared for.
The audit sees that a record exists, what its classification is, and who signed it. It does not expose what the record says: content and embeddings never cross the compartment boundary, even for the auditor. The audit walks around the boundary rather than through it. An auditor can confirm, for instance, the distribution of records across classification levels and compartments, and that every operator signature is valid — without reading a single classified record.
A Gov-mode SERAPH store is a single, portable file that answers — with cryptographic proof rather than institutional trust — all of the following at once:
- What was recorded — every record, in order, with content commitments.
- At what classification — bound into the chain, so silent reclassification is impossible.
- In which compartments — enforced on every access.
- Who recorded it — the individual operator, verifiable offline.
- When — bounded by trusted external time, independent of the local clock.
- Whether anything changed after the fact — any tampering with content, classification, attribution, or ordering breaks the chain at the exact point it occurred.
The store is the evidence; the chain is the proof. A recipient can verify a sealed Gov-mode store's entire provenance — integrity, classification, attribution, and temporal bounds — using only the file and the verification tool, with no database, no network, and no trust in the sender's environment.