Every process card, decision, and procedure in Synaura is cryptographically signed by the authenticated user who records it and tamper-evident over time. When an executive asks "who decided this and when," Synaura answers with a mathematical proof — not a Slack screenshot. Built on post-quantum cryptography from day one.
Most knowledge tools store text and trust the database. If a row gets edited — by an admin, by an integration, by a bad actor — there is no way for a downstream reader to know. The audit log itself can be edited. The screenshot can be faked. The "source of truth" has no source.
Synaura is different. Every artifact carries its own proof of origin, signed at the moment of creation or update by the authenticated user who made the change, using the organization's cryptographic signing key. The data does not need to trust the database. Anyone with the public key can verify the signature independently.
Operational procedures, runbooks, and how-we-do-X knowledge. Signed by the authenticated user who creates or edits them.
Extracted step-by-step workflows. Signed by the authenticated user who reviews and approves them.
Approvals, sign-offs, and resolutions recorded in Synaura. Decisions can be initiated through any product surface — including AI-suggested ones — but the cryptographic signature is always tied to the authenticated user who recorded the decision.
Every change is itself a signed event in an append-only chain. Each event links to the hash of the previous one. History cannot be rewritten without breaking the chain.
Content is canonicalized (sorted-key JSON, UTF-8), hashed, and signed with the org's ML-DSA-65 key.
The signature, signer identity, and content hash are persisted atomically alongside the artifact and its event chain.
Public endpoints return the signature, public key, and content — enough for independent verification. No Synaura access needed.
Public verification endpoints are live today:
// No authentication required
GET /processes/{id}/verify
GET /decisions/{id}/verify
GET /procedures/{id}/verify
// Append-only event history with chain integrity
GET /processes/{id}/history
GET /decisions/{id}/history
GET /procedures/{id}/historySynaura's signatures use ML-DSA-65, the NIST-standardized post-quantum signature algorithm published in FIPS 204 in August 2024. This is the same algorithm being adopted by U.S. federal agencies under the NIST IR 8547 transition mandate.
| Algorithm | ML-DSA-65 (FIPS 204) |
| Security level | NIST level 3 (≅ AES-192) |
| Quantum-resistant | Yes |
| Implementation | @noble/post-quantum (audited) |
| Canonicalization | Sorted-key JSON, UTF-8, SHA-256 |
| Signature encoding | Base64 (4,412 chars) |
| Signing key scope | Per-organization |
| Event chain | SHA-256 hash-linked, append-only |
| Artifact types | process_card, decision, procedure |
Synaura separates content hashing from signature attribution, similar to how Git separates tree hashes from commit hashes. The content hash covers only the artifact's domain fields — title, status, steps, rationale — and is used to detect whether content actually changed. The full signed payload adds signer_user_id and signed_at_crypto before signing. This means re-saving an artifact without changing its content produces no new signature, while a genuine edit is always cryptographically attributed to the user who made it.
This is production data from Synaura's live environment — a real decision artifact with its actual signature. Truncated for display; the full signature is 4,412 base64 characters.
// Canonical payload (sorted-key JSON, SHA-256 hashed before signing)
{
"algorithm": "ML-DSA-65",
"category": "general",
"confidence": 0.7,
"decided_by_name": "R. G.",
"id": "dec_v4_01",
"org_id": "org_renan",
"signed_at_crypto": "2026-05-07T12:37:39.530Z",
"signer_user_id": "usr_renan_01",
"status": "approved",
"summary": "Cost reduction of 40% vs AWS. Better DX...",
"title": "Migrate all edge compute to Cloudflare Workers",
...
}
// Signature (ML-DSA-65, base64, 4,412 chars)
"0ylzJmC9z7ZMnrpBT31nUQp4Y5cn5JTTgr8bBDMl9/Z98AKbj75s
Y7VCAK7XCm+KFF135YJH/8YC/LwIZgVXf2OrXiUkf5MpFsm+t5Yz
rj4a9SygwQw6/u+/0p3mLVkbopCiwVsv4dx6YLH4uPFRQUSkW7GZ..."
// Content hash (SHA-256 of domain fields only)
"signed_payload_hash": "7ab4252cca602d86d0c425ef91d50851
061d0e34756250a298bad5c5a234f39c"
// Public key reference
"public_key_id": "skey_4c2ef7c41af243"Every create, edit, and delete in Synaura is recorded as an immutable event. Each event carries an event_content_hash (SHA-256 of its payload) and a prev_event_hash linking it to the previous event for that artifact. Tampering with any event's payload invalidates its hash; tampering with the hash breaks every subsequent link in the chain.
// Event chain for decision dec_v4_01
{
"id": "evt_81d25d1b542e4b",
"artifact_type": "decision",
"artifact_id": "dec_v4_01",
"event_type": "create",
"sequence": 0,
"prev_event_hash": null, // genesis event
"event_content_hash": "946f5674d54e4453...",
"created_at": "2026-05-07T13:07:18Z"
}As of today, Synaura's production environment holds 98 events across 94 artifacts — 91 backfilled from pre-signing data (flagged is_legacy), 7 live-signed events with full chain integrity.
If you're evaluating Synaura for compliance-sensitive use cases — regulated industries, board-level decisions, AI agent oversight, customer-facing knowledge — the provenance layer answers four questions you should be asking any knowledge tool:
No. There is no chain, no consensus, no token, no gas. This is straightforward digital signature cryptography — the same primitive that secures TLS, SSH, and code signing — applied to every artifact Synaura stores. Verification is local and instant.
Signing keys are scoped to the organization, not individual users. The private key is stored encrypted at rest, isolated per-org. The public key is stored in the database and served through the verification endpoints. Individual users never handle raw key material — signing happens server-side when an authenticated user creates or edits an artifact.
The signed_at_crypto timestamp is bound to the signature — changing it invalidates the proof. However, the timestamp is currently attested against Synaura's server clock, not an external time authority. This means Synaura can prove what was signed and by whom, but the when is only as trustworthy as Synaura's infrastructure. External timestamp anchoring is on the roadmap (see below).
The cryptographic core is built on @noble/post-quantum, an audited open-source implementation of FIPS 203/204/205 by Paul Miller. Synaura does not implement cryptographic primitives — we use audited ones. The canonicalization layer (sorted-key JSON, SHA-256, two-level content vs. attribution hashing) is reviewable.
Pre-existing artifacts are backfilled into the event chain with the is_legacy flag set. They appear in history but carry no cryptographic signature. We do not retroactively claim signatures on data we cannot prove the origin of.
No. AI can propose decisions, extract procedures, and suggest process cards, but the cryptographic signature is always tied to the authenticated user who reviewed, approved, or recorded the artifact. There is no concept of an "agent signature" in the provenance model.
Shipped features are described above. The following capabilities are planned but not yet in production.
public_key_id resolution per eventrestore event appended to the chainSynaura is institutional knowledge mid-market companies can stand behind. Provenance is one of the reasons.