Used to confirm the current organization-framing around autonomous intelligence, persistent agents, and the public research / docs entrypoint
The homepage HTML currently includes Organization schema whose description says: Ritual Labs builds the sovereign AI network — useful direct evidence that the named builder entity is Ritual Labs, not only the chain brand Ritual
Used to confirm that the same public site keeps the Ritual Labs builds the sovereign AI network organization-schema framing while presenting the broader institutional thesis around open AI infrastructure
Used to confirm that the canonical chain docs are currently hosted on a separate ritualfoundation.org domain rather than only under ritual.net, which is a useful signal that the public project surface is already split across at least a Labs-branded builder shell and a Foundation-branded documentation / protocol shell
Used to confirm the practical control surfaces around the chain: TEEServiceRegistry, RitualWallet, AsyncJobTracker, Scheduler, AsyncDelivery, AgentHeartbeat, and ModelPricingRegistry, plus the delegated-compute and executor-attestation model
Primary-source takeaways
The cleanest project/company split is: Ritual for the delegated-compute chain architecture, and Ritual Labs for the named builder / distribution / implementation shell above it.
The organization boundary is not inferred only from venture coverage or social profiles; the official ritual.net site itself uses Organization schema whose description explicitly says Ritual Labs builds the sovereign AI network.
The docs being hosted at docs.ritualfoundation.org matter analytically because they suggest the public-facing protocol surface is already not a single undifferentiated brand. Even before a fuller foundation note exists, the corpus benefits from distinguishing the protocol from the named builder shell.
The architecture docs make the live operator-shaped surfaces legible: executor admission via TEEServiceRegistry, fee and lock discipline via RitualWallet, async job management via AsyncJobTracker, callback delivery via AsyncDelivery, agent persistence via AgentHeartbeat, and model availability / pricing configuration via ModelPricingRegistry.
That combination makes Ritual Labs worth a selective promotion into companies/: the useful question is not only how does Ritual's delegated-compute chain work? but also which named organization is packaging, presenting, and likely steering the easiest implementation and distribution path around those chain-level control surfaces?
Why it matters for the corpus
It gives the company taxonomy a better foothold in the crypto × AI cluster, which otherwise risks flattening named builder / operator shell and protocol architecture back into one note.
It creates a reusable promotion test for AI-chain and delegated-compute systems whose chain mechanics are real, but whose public builder narrative, docs entrypoint, and likely operator defaults still concentrate around one named organization.
It also prepares the corpus for a later foundation-versus-labs map if Ritual’s governance, docs, or validator / executor governance becomes more explicit.
Follow-up comparison threads
Compare Ritual Labs against fhenix when the question is not what privacy / compute primitive exists? but which named company packages and steers the main implementation and rollout shell?
Compare Ritual Labs against megaeth-labs and espresso-systems when the question is who sits at the implementation-authority layer for a novel execution stack rather than only what the protocol promises.
If better primary sources surface later, split a separate Ritual Foundation note only if the foundation boundary becomes concrete enough to answer distinct questions about governance, docs stewardship, validator / executor admission, or treasury / upgrade authority.