Architecture

How Stelais, the Akaeon Registry, the core packages, and Arweave fit together — and what to omit from the diagram on purpose.

The job of the diagram: make four facts visible at a glance.

  1. There is a shared, brand-neutral substrate (the @akaeon/core-* packages).
  2. Stelais consumes that substrate today, in production.
  3. The Akaeon Registry is a second consumer of the same substrate — same primitives, different API surface, different consumer.
  4. Both ultimately produce records anchored to Arweave — the public, permanent, third-party-operated trust root.

The rendered diagram lives on the registry overview page. This page is the long-form treatment: what the diagram is saying, and what it deliberately leaves out.

What the diagram is saying — in words

The diagram is laid out as three horizontal bands stacked top-to-bottom:

Top band — Consumers. Two boxes side by side. The left box is Stelais today, with stelais-web and stelais-api inside it. The right box is the Akaeon Registry, with akaeon-registry inside it. The visual symmetry is the point — the registry is peer to Stelais, not a child of it.

Middle band — @akaeon/core-*. Four sub-boxes side by side. Each represents one published workspace package. Both top-band consumers draw lines down into this band — Stelais into arweave / verification / fingerprinting / watermarking, the registry into arweave / verification / fingerprinting. The same boxes are touched by both consumers. The labels on the edges (app: 'stelais' vs app: 'akaeon-registry') make explicit what differs — only the brand-coupling parameter — and what doesn't — the code underneath.

Bottom band — Arweave. One node. Both consumers' core-arweave package writes to it. The label inside the node distinguishes the two modes ("per-record tx today" for creator proofs; "Merkle-root tx for registry batches" for the higher-throughput opt-out path).

Floating below — the third-party verifier. This box does not belong to Stelais or the registry. It belongs to whoever is checking the proof — the AI lab's compliance team, a court, an auditor, a competing service that wants to import our proofs. Two paths point at it: one from Arweave directly (read the on-chain payload), one from each consumer's public verify endpoint. The verifier doesn't run Stelais code or registry code to do its job.

How this supports the rest of the pitch

Three concrete moments where this diagram does work:

  1. The 30-second elevator answer to "how does this fit together?" Point to the middle band: "Brand-neutral primitives, here. Both products consume them with their own brand parameters. The substrate underneath is Arweave. That's the architecture."
  2. The pivot in the production walkthrough. After demonstrating the substrate in production, trace your finger from stelais-api through core-arweave into Arweave. Then trace it from akaeon-registry through the same core-arweave into Arweave. The shared path is the sale.
  3. The concrete example at the moment where the publisher opt-out payload reaches core-arweave. The diagram tells the reader: this is the exact same primitive that anchored the creator proof in the production walkthrough.

What the diagram deliberately omits

Things that look natural to put in this diagram but actively hurt the conversation:

  • The Postgres database — both consumers have one, but storage is not what the diagram is about. The trust root is Arweave; the database is implementation detail.
  • The BullMQ retry queue — same reasoning. Operational, not architectural.
  • R2 / object storage for raw files — Stelais stores raw uploads in R2 but never anchors raw files to Arweave. Showing R2 invites the wrong question ("how do you trust the file content?") when the right question is already answered by the content hash being signed and anchored.
  • The fingerprinting pipeline as a separate horizontal band — the primitives are in core-fingerprinting; the orchestration is per-consumer. Hoisting it into its own band overstates how much shared logic exists around fingerprinting today.
  • The AI lab as a separate top-band consumer of the registry — the lab is a verifier, not a consumer in the workspace-dep sense. They call the registry's lookup endpoint over HTTP; they don't import core packages. Putting them in the top band would muddle the meaning of "consumer."

If the diagram supports the three moments above and nothing else, it's earned its place. If it starts accumulating boxes to answer follow-up questions ("but what about auth?", "where does Sentry go?"), it has crept toward the enterprise-architecture failure mode the brief warned against — make a second diagram for those questions instead of overloading this one.

The brand-coupling rule, made concrete

The core packages have one rule: every brand-specific parameter is a required argument with no default. The package throws if called without one.

| Parameter | Stelais value | Registry value | |---|---|---| | app | 'stelais' | 'akaeon-registry' | | network | 'arweave' | 'arweave' | | Canonical message prefix | 'stelais:proof:v1' | 'akaeon-registry:optout:v1' |

The packages contain no string literal of either consumer's brand. This is verifiable by grep in the core source tree. The same code paths sign Stelais creator proofs and registry opt-out records; the difference is the parameter passed at the call site.

This is the diagram's load-bearing claim: same code, different parameters.