The architecture
Trust infrastructure earns nothing by being mysterious.
Palynth is one system with two halves that prove each other. A capsule carries a document together with proof of every claim inside it, down to the bytes that state it, and reopens offline years later byte for byte. A ledger carries the history across documents: an append-only, hash-chained record of every event, so any change can be traced to what caused it and, through the capsule, to the exact operators that say so. The trust core is small, deterministic, and checkable: the same input produces the same hash on three independent implementations, which is a property you can test rather than a claim you have to accept.
The trust core
Canonicalization
Every event is serialized to one deterministic form: keys sorted recursively, undefined dropped, numbers written exactly. Hashing depends on byte-stable input, so this is the only place bytes are decided.
Event model
Append-only. Corrections are new events that reference what they correct; nothing is edited and nothing is deleted. The event vocabulary is open, and payloads are opaque to the kernel, so a new discipline never requires a schema change.
Hash chain
Each event carries the SHA-256 of its own canonical form plus the hash of the event before it. Alter any historical value and that event stops matching its own fingerprint, and every event after it stops matching the chain.
Permanent identity
Assets carry a UUID that never changes. Drawing numbers are aliases with effective revision ranges. Matching across revisions is weighted over identifier, dimensions, room, wall, schedule position and connected hardware, so a renumbered door stays the same door.
Temporal relationships
Properties and relationships are intervals with an opening and closing revision. They close, never delete, which is what makes any past revision reconstructible rather than merely logged.
Graph traversal
Impact propagation walks typed edges from the changed asset outward, recording per-node reasoning and evidence references. Staleness compares when an artifact was generated against when its inputs last changed.
Merkle rollup
Event hashes roll into a single root per project. The root is what an external anchor would sign.
What runs today, and what does not
Read this before anything else on the site. Nothing marked experimental or roadmap is described elsewhere in the present tense, and no capability appears in the marketing copy that is absent from this table.
| Capability | Status | What is actually true |
|---|---|---|
| Canonicalization, SHA-256, hash chaining | Live | Three independent implementations agree byte for byte, pinned by golden vectors. |
| Chain and tamper verification | Live | Runs server side and in your browser. Identifies the exact event altered. |
| Merkle root per project | Live | Real tree, real root. |
| Asset identity, aliases, temporal facts | Live | Weighted resolution. Never assumes the same number means the same asset. |
| State reconstruction | Live | Folds the ledger to any revision. |
| Impact traversal, staleness, causal trace | Live | Graph traversal with reasoning and evidence references per node. |
| Document fingerprinting | Live | SHA-256 over document content, verified on read. |
| Production event writing | Live | Extraction jobs append events to real project chains. |
| Document capsule with operator provenance | Live | A PDF and its evidence in one verifiable container, recoverable byte for byte. |
| Capsule to ledger evidence bridge | Live | The production pipeline compiles a capsule per extracted document and pins every event it can to the operators that state it. No page, no pin, reason named. |
| Evidence pinned inside events | Experimental | One implementation only. Both kernels must agree before production can emit it. |
| External anchoring of the project root | Roadmap | Not operational. The root is computed and published, and nothing external signs it. |
| Durable provenance persistence | Roadmap | Schema exists and is not yet applied. Chains currently live in the extraction database. |
| Disciplines beyond doors and hardware | Roadmap | The model is trade generic by construction. Only doors and hardware has run against real projects. |
| Cross project learning | Roadmap | Out of scope by design. |
Questions evaluators ask that this does not answer yet
Four things a technical buyer looks for and will not find. Absent is not the same as planned-and-hidden, so they are listed rather than left to be discovered on a call.
Is there a public API?
No. The engine is a set of libraries and a CLI, consumed inside the extraction pipeline. There is no hosted API, no SDK, and no authentication layer to speak of.
Does it integrate with our document systems?
Not today. Palynth reads output from one extraction pipeline. There are no connectors to construction document management platforms, and building one has not started.
Who holds the record?
Currently the same party that runs the extraction. There is no separate custody model, no per-tenant isolation story worth claiming, and no export format for handing a chain to someone else.
How does it behave at project scale?
Unmeasured beyond the projects it has processed. Chains of a few dozen to a few hundred events verify in milliseconds. Nothing here has been load tested.
On the word blockchain
Palynth uses a chain of cryptographically linked events. That is the same machinery, minus everything that made the word radioactive: no token, no coin, no wallet, nothing to trade, nothing for sale.
What is kept is the part that lets a record prove it has not been altered. What is not kept is distributed consensus, which solves a problem Palynth does not have. A project chain has one writer and many readers, so the useful property is tamper evidence, not trustless agreement between strangers.