Platform · 4. How they fit together
This chapter is explanation. It draws the whole platform as one picture and answers the question the individual reference chapters cannot: in each way you might deploy this, what leaves your control and what does not.
The spine of the answer is one sentence:
Crux Engine is the hosted plane. CoreCrux is the substrate it reads. The Crux Daemon is the same capability, local.
Everything below is that sentence with its consequences worked out.
4.0 In plain English
The previous chapters each describe one system. This one answers the question none of them can, which is what happens when you actually deploy something: what runs on your hardware, what runs on ours, and which of your data crosses the line between the two.
That question has more than one answer because there is more than one way to run this. You can run the daemon entirely on your own machine and never talk to us. You can use the hosted plane and run nothing. There are shapes in between. Each shape moves the boundary of what stays yours, and the boundary is the thing that matters to anyone who has to sign off on the decision. §4.5 lays out all four shapes with that boundary drawn explicitly for each.
The reason a chapter is needed rather than a diagram is that the systems share contracts deliberately. The same receipt formats and the same capability-token scheme appear in the local daemon and in the hosted plane, which is what makes it possible to start local and move hosted, or the reverse, without rewriting your client. Shared contracts are also what make the four components easy to confuse, because the same words come back in each of them meaning almost but not quite the same thing.
You will want this chapter when you are choosing a deployment shape, and again when someone in your organisation asks the data-residency question and expects a straight answer. §4.6 is the practical companion to that conversation: it tells you how to determine, from a response you are holding, which shape actually served it, rather than which one you believe you configured.
The thing people get wrong is the word "engine", and §4.2 exists solely to head it off. It appears in more than one product name and in the ordinary English sense as well, so a sentence about "the engine" can mean the hosted service, the retrieval substrate underneath it, or neither. When you read that word anywhere in this documentation set, check which system the chapter is about before you draw a conclusion from the sentence.
4.1 The four components, in one table
| Component | What it is | Open or closed | Who runs it | Chapter |
|---|---|---|---|---|
| Crux Daemon | A local-first memory and retrieval daemon for one developer's agents. One binary, CPU-only, no account. | Open source under Apache License, Version 2.0 | You, on your own machine | Daemon guide |
| Crux Engine | The hosted platform service. Ingest, retrieval, answers, receipts, identity and tenancy over an HTTP API. | Closed | CueCrux | 1. Crux Engine |
| CoreCrux | The proprietary retrieval and event-storage engine. GPU-resident, multi-tenant, the substrate under the hosted plane. | Closed | CueCrux, or you on your own hardware | 2. CoreCrux |
| FeatureCrux | The internal control plane that resolves which runtime behaviours apply to a tenant and a request, and records the decision. No public endpoint, no SDK, no account reaches it. | Internal | CueCrux | 3. FeatureCrux |
Plus the surfaces, the web frontdoor, the documentation site you are reading, the wiki, and the agent-facing MCP tool surfaces. These are consumers of the contracts below, not components with their own guarantees.
Two supporting services are worth naming because they explain a dependency rather than adding a capability: an embedding service, which produces dense vectors and which neither CoreCrux nor Crux Engine hosts internally, and a local inference service for on-premises model execution. Both are separate processes by design.
4.2 A caution about the word "engine"
Two different things in this platform have been called "the engine", and the distinction determines which endpoint you call.
Crux Engine is the hosted platform service. It runs on CueCrux infrastructure and you reach it over HTTP with an API key or an OAuth bearer. CoreCrux is the substrate engine that Crux Engine reads from. Separately, the Crux Daemon has its own local retrieval path, which is neither of those two things.
If a document tells you that the engine "ships inside the daemon", it is describing the daemon's local retrieval path and should not be read as describing the hosted service. 1.1 sets this out in full.
4.3 What talks to what
your agents / your app / your SDK
| |
| (local) | (hosted)
v v
Crux Daemon ------------> Crux Engine
(your machine) rcx-ct (hosted plane)
| capability |
| token v
v CoreCrux engine
local data dir |
+--> embedding service
+--> local NVMeRead the arrows carefully, because three of them are commonly drawn wrong.
Your application never talks to CoreCrux directly. In the hosted shape, the caller is always Crux Engine. Nothing in a public web tier reaches the substrate.
The Crux Daemon does not sit under Crux Engine. It is a peer, not a layer. The daemon is what a developer installs; Crux Engine is what an operator deploys for a fleet. Either can serve the same consumer.
A daemon that calls a hosted backend does so under a capability token, not under your account credentials. The token names the tenant, the backends, the capabilities and the exact classes of data permitted to leave. That is the hybrid shape, and it is the reason the arrow between them is labelled.
Control planes are admin-only, and FeatureCrux is not on the diagram because it is not in the data path. No control plane proxies append or read traffic, or parses event frames. FeatureCrux sits beside the request path: a consumer asks it which runtime behaviours apply at the start of a unit of work and carries the answer forward, and the resolved set is recorded. A control-plane outage does not take reads down. See 3. FeatureCrux, including the boundary on what that record is and is not an inventory of.
4.4 The contracts they share
The platform's coherence is a small set of contracts that hold across every component. This is what makes moving between local and hosted a deployment decision rather than a rewrite.
| Contract | Shared by | What it means for you |
|---|---|---|
| CROWN receipt format | Daemon, Crux Engine, CoreCrux | The same receipt shape and the same verification recipe everywhere. A receipt produced locally and one produced hosted are checked the same way. |
| Ed25519 signing and BLAKE3 content addressing | All | Standard primitives. Execution receipts are signed; retrieval receipts are content-addressed and are not signed. See 1.13, the distinction survives across components and must not be collapsed. |
| Pointer-first response contract | Crux Engine, CoreCrux | Results carry identity, ranking and cost metadata by default; content is hydrated in tiers. The full legacy payload is opted into with Accept-Contract: legacy. |
/v1/query/* route shapes | Daemon, CoreCrux | A consumer written against the Community Edition keeps working when pointed at the private engine. |
rcx-ct capability tokens | Daemon, Crux Engine | The delegation scheme. Same token structure, same refusal codes, same revocation reasons on both sides. |
X-Crux-Mode response header | Daemon, Crux Engine | Tells you which plane actually served a request, including when it was degraded or refused. |
| RFC 7807 problem details | All | Errors are application/problem+json with a type, title, status and actionable detail. |
| Health, readiness, metrics trio | All | /healthz, /readyz, /metrics as a contractual integration surface. /readyz returns 503 when a component is not ready to serve. |
4.5 The four deployment shapes, and what stays yours
This is the point of the chapter. Each shape is described by what leaves your control, not by what it costs.
| Local only | Hosted | Hybrid | Customer-hosted substrate | |
|---|---|---|---|---|
| What you run | Crux Daemon on your machine | Nothing | Crux Daemon on your machine | CoreCrux on your hardware |
| What we run | Nothing | Crux Engine and CoreCrux | Whichever hosted backends your token names | Nothing in the serving path |
| Where your corpus lives | Your disk | Your tenant on our hardware | Your disk | Your disk |
| What crosses the network | Nothing | Your queries and your documents | Only the egress classes your capability token names | Nothing, if the embedder is co-located |
| Account required | No | Yes | Yes, for the hosted backends | No licence server in the serving path |
| Verification | Local, offline | Public and unauthenticated | Either | Local, offline |
4.5.1 Local only
You install the Crux Daemon, it binds to loopback, and nothing leaves the machine. There is no account, no API key and no phone-home. Receipts are produced locally and verified locally, offline.
What stays yours: everything. The trade is capability, not trust, the daemon is CPU-only and single-user, and the multi-tenant, GPU and scale capabilities in the capability split are not present. Dense retrieval is bring-your-own and optional; the default path is lexical and graph.
4.5.2 Hosted
Your corpora live in your tenant on our hardware and you reach them over the /v1 API.
What stays yours, concretely:
Tenant scoping is enforced twice, at the credential and again at the query, and a header-versus-body tenant disagreement is refused rather than reconciled. Corpora are private unless you mark them commons.
Receipts you hand to a third party carry quoteHash, not the quoted text, so a receipt discloses provenance without disclosing your content.
Verification is public and unauthenticated. Your auditor checks a receipt at /v1/receipts/verify and fetches signing keys from /.well-known/crown-keys without an account and without asking our permission. A proof only the issuer can check is not a proof.
Deletion is verified after it commits and reports erasure_verified, and a tenant-wide erasure path exists.
What does not stay yours, said as plainly: we hold the data and we operate the machines. There is no latency or availability SLA, see 1.19. Governance-tier entitlements are granted but not enforced, and billing features are gated off and not live. Do not build an assurance argument on any of those three.
4.5.3 Hybrid: local daemon, hosted backend
Your data stays on your machine and the daemon calls a hosted backend for the work it cannot do locally, under an rcx-ct capability token.
The token is the boundary, and it is an enforced one rather than a policy statement. It names the tenant, the permitted backends, the permitted capabilities, and, the field that matters most here, the data_egress_classes permitted for each capability. A token that permits only receipt_hashes cannot be used to move prose off your machine; an attempt is refused with egress_not_permitted before anything leaves.
Refusals are named, not generic: twelve refusal codes distinguish an expired token from a revoked one from a tenant mismatch from an egress violation. Revocations state their reason. And every capability-mediated response is stamped with X-Crux-Mode, so you can always tell whether you were served locally, served hosted, served by a degraded local path, queued, or refused.
What stays yours: the corpus, and a per-capability, machine-enforced statement of exactly what may leave it. What you take on: the daemon is now a participant in a distributed system, and you should treat degraded-local and degraded-queued as first-class outcomes in your client rather than as errors.
4.5.4 Customer-hosted substrate
CoreCrux runs on your hardware. Data lives in the data directory on your node.
The engine's only outbound dependency in the serving path is the embedding service, and that service is self-hostable, so a fully air-gapped deployment is achievable by co-locating the embedder. There is no external vector database, no managed control plane, no telemetry requirement and no licence server in the serving path. Telemetry export exists and is your choice.
What stays yours: the data, the hardware and the network posture. What you take on: GPU operations, capacity, backups, and the part of erasure the engine cannot reach. Erasure covers the live data directory; your backups, snapshots and replicas are yours to erase, and an erasure guarantee that claimed otherwise would be a guarantee about your filesystem rather than ours.
4.6 How to tell which shape actually served you
A design that lets you reason about the boundary is worth little if you cannot observe it at runtime. Three signals do that work, and they are the same three in every shape.
X-Crux-Mode on the response says which plane served the request, local, hosted, customer_hosted, degraded-local, degraded-queued or refused. There is no unlabelled degradation.
The error.type and, on a capability refusal, the reason_code say why something did not happen. Only RateLimited and UpstreamDown are recoverable; everything else is a condition on your side and retrying will not change it.
/readyz returns 503 rather than serving a silently degraded path, including, on CoreCrux, when the high-throughput storage path is configured but not genuinely engaged.
4.7 What none of the shapes promise
Read this section as the counterweight to everything above. These limits hold in every deployment shape.
No latency or availability SLA exists anywhere in the platform. A benchmark figure, a tookMs on a response, a cache header or a healthcheck interval is an observation or a configuration value. If you need a service level, ask for a commercial one.
Receipts are not attestations of conduct. A receipt is a verifiable record of what was stored and retrieved. It is tamper-evidence. It does not prove what an agent did in the world.
Execution receipts are signed; retrieval receipts are not. Retrieval receipts are content-addressed over canonical inputs, and verification is membership in the public benchmark receipts table. If your control requires an issuer signature, you need an execution receipt.
There is no customer-facing replay endpoint. Verification is offered. Replay of an arbitrary past query against historical corpus state is not, and any earlier copy that promised it was wrong.
Semantic search is not on by default in the Community Edition. Dense retrieval there is bring-your-own and optional; the default path is lexical and graph. On CoreCrux dense is first-class, and it depends on an external embedding service that can be unavailable.
Governance-tier entitlements are granted but not enforced, and billing features are gated off and not live.
Mechanism is not published, and will not be. Scoring formulas, fusion constants, index formats, lane inventories and weighting, rewriting strategy, GPU internals, environment and flag surfaces, and internal module and table names are absent from these chapters deliberately. Contracts, routes, request and response fields, headers, scopes, status codes and error codes, are published in full, because withholding a contract helps nobody.
4.8 Where to go next
| If you want to | Read |
|---|---|
| Integrate against the hosted API | 1. Crux Engine |
| Understand the substrate, or evaluate self-hosting it | 2. CoreCrux |
| Understand how runtime behaviour is decided per tenant and recorded | 3. FeatureCrux |
| Run the daemon on your own machine | Crux Daemon developer guide |
| Verify a receipt someone handed you | 13. Receipts and proof, then 5.1 What a receipt proves, and what it does not |