How Genesis Mesh Works

Genesis Mesh is a trust, policy, authorization, and evidence layer for interactions between machines, services, agents, people, and organizations.

It does not require every participant to give control to one central authority. Instead, it provides a way to establish identity, define authority, make signed decisions, delegate rights, revoke trust, and prove what happened.

Genesis Mesh is the overall system that connects the concepts in this guide.

It can be used inside one organization or across multiple independent organizations.

Think of a system that combines identity documents, contracts, policy rules, approval decisions, delegated authority, revocation, and an official evidence archive.

Each part has a different job, but together they create a complete trust model.

A Sovereign is an independently controlled Genesis Mesh trust domain.

It owns its own keys, policies, authority, state, and trust decisions.

A Sovereign is the top-level ownership boundary.

Different organizations can each operate their own Sovereign without giving control of their trust domain to another organization.

Think of an independent country or company.

It has its own rules, identity system, and decision-making authority. It can cooperate with others without giving up control of itself.

The Root Sovereign is the cryptographic root of trust for a Sovereign.

It establishes the identity of the trust domain and anchors the authority that operates below it.

It is typically kept protected and is not intended for normal day-to-day operations.

The Root Sovereign establishes the Genesis Block, which in turn anchors the Network Authority.

Root Sovereign
      ↓
Genesis Block
      ↓
Network Authority

Think of the founding legal documents of an organization.

They are not used for every daily action, but they prove where the organization's authority originally comes from.

The Genesis Block is the immutable root document that establishes the Sovereign.

It identifies the trust domain and anchors important information such as the root public key and the Network Authority.

Everything that follows can trace its trust back to the Genesis Block.

It provides a stable answer to:

Where did this authority come from?

Think of an organization's certificate of incorporation or constitutional document.

It establishes the organization and the authority structure that follows from it.

The Operator Key authenticates privileged administrative actions against the Network Authority.

It can be used for actions such as publishing policy, issuing or revoking attestations, registering executor identities, and changing trusted administrative state.

The Operator Key is for governance of the authority itself.

It is separate from the identities that execute normal workload actions.

Think of an administrator credential that can change official rules and register trusted users.

A normal worker may execute approved work, but only an authorized administrator can change the system of authority.

The Network Authority (NA) is the main Genesis Mesh control-plane authority.

Depending on the capability in use, it can manage attestations, evaluate policy, sign authorization decisions, manage recognition and revocation state, register trusted executors, and store evidence.

The Network Authority is the active authority underneath the Sovereign.

The Root Sovereign establishes trust. The Network Authority performs the day-to-day trust and policy work.

Think of a central public administration.

The constitution establishes its authority, but the administration performs the daily work of issuing official decisions, maintaining records, and applying rules.

A Node is a cryptographically enrolled Genesis Mesh peer.

It has its own key material and a Join Certificate proving that it was admitted into the trust domain.

Nodes are useful when trust or enforcement needs to be distributed closer to workloads, edge environments, or other participating systems.

Not every application or executor needs to be a Node.

Think of an officially registered branch office.

It has its own local identity, but it is recognized as part of the wider organization.

An Invite Token is a single-use authorization used to enroll a new Node.

It is part of the Node enrollment process.

Invite Token
      ↓
Enrollment
      ↓
Join Certificate
      ↓
Node

Think of a one-time invitation to join a private organization.

The invitation lets someone begin enrollment, but it is not the permanent identity they use afterwards.

A Join Certificate is a short-lived Network Authority-signed certificate that proves a Node was admitted into the trust domain.

After a Node is enrolled, the Join Certificate becomes the Node's proof that it is a recognized participant.

Think of an official staff badge issued after an employee has completed onboarding.

The invitation allowed them to apply. The badge proves they were accepted.

A CRL (Certificate Revocation List) is a signed list of Node certificates that should no longer be trusted.

A Node may be revoked because it was retired, its key was compromised, the system was decommissioned, or trust was withdrawn.

The CRL lets trust be removed before a Join Certificate naturally expires.

Think of a security office publishing a list of access badges that have been cancelled even though the printed expiry date has not yet passed.

An Agent is a workload or autonomous actor that can perform useful operations.

An AgentDescriptor is a signed description of that agent, including information such as its capabilities and endpoint.

Agents allow Genesis Mesh to represent active machine actors, not only infrastructure peers.

An Agent can participate in trusted workflows where its identity and capabilities need to be understood.

Think of an employee and their official job profile.

The employee is the actor. The job profile describes what they do, what capabilities they have, and where they operate.

An AgreementRecord is a dual-signed agreement between two independently governed parties.

It defines what capabilities or terms both parties agree to.

An AgreementRecord is useful when authority is based on mutual agreement rather than one party simply issuing an internal permission to another.

Think of a contract signed by two companies.

Both sides agree to the same terms, and both signatures matter.

A Recognition Treaty is a signed, scoped, and revocable recognition relationship between two independent Sovereigns.

It enables two independently controlled trust domains to recognize each other without either domain becoming subordinate to the other.

Sovereign A
     ↕
Recognition Treaty
     ↕
Sovereign B

Think of two countries agreeing to recognize certain official documents issued by each other.

Each country remains independent, but they establish explicit rules for cooperation.

A Recognition Policy defines the local rules for what an external Sovereign, attestation, or trust statement is accepted for.

A Recognition Treaty establishes a relationship.

Recognition Policy decides what the local domain actually accepts through that relationship.

Two countries may recognize each other diplomatically, but that does not mean every document from one country is automatically valid in the other.

Local law still defines what is accepted and for what purpose.

A DelegatedAgreementRecord allows an authorized party to delegate a narrower subset of its authority to another identity.

The delegated authority must remain inside the authority originally granted.

It supports chains such as:

Organization
     ↓
Platform
     ↓
Team
     ↓
Workload

Each level can receive only the authority that the previous level is allowed to delegate.

Think of a power of attorney.

If someone authorizes you to pay a bill on their behalf, you cannot use that authority to sell their property.

Delegation cannot exceed the original permission.

A Sovereign Revocation Feed is signed revocation information exchanged between Sovereigns.

It allows one domain to learn that another domain has withdrawn trust from an identity or trust artifact.

Cross-domain trust is only safe if revocation can also cross the boundary.

Think of an issuing authority informing another organization that a previously valid passport, certificate, or professional license has been cancelled.

A FreshnessProof is signed proof that revocation information was current enough when an authorization decision was made.

It answers an important audit question:

Was the system making its decision using recent enough trust information?

It is not enough to show a list of cancelled credentials.

An auditor may also ask:

When was this list last updated?

FreshnessProof provides evidence about that timing.

An Invocation-Bound Capability Token (IBCT) is a short-lived, tightly scoped capability token that can be verified without a live call to the Network Authority for every operation.

IBCT can support high-volume operations, latency-sensitive systems, disconnected environments, and edge workloads.

Instead of calling headquarters every time someone opens a door, headquarters issues a badge valid for five minutes and only for one specific door.

The local system can verify the badge without calling headquarters each time.

Human Oversight allows sensitive authorization to require both an automated identity and a human approval key.

A Dual-Signed Commitment provides cryptographic evidence that both sides approved the action.

This is useful when automation should be allowed to operate, but certain high-risk actions still require explicit human involvement.

Think of a high-value bank transfer that requires both the automated payment system and an authorized manager to approve it.

Consensus Authorization requires a threshold of independent validators before a consequential action is authorized.

For example:

5 validators exist
3 approvals required
3 of 5 → authorized
2 of 5 → not authorized

It reduces dependence on a single approver for highly sensitive operations.

Think of a board resolution that requires a minimum number of members to vote in favor before the decision becomes valid.

Selective Disclosure allows an identity to prove a specific capability or property without revealing its complete capability set or identity data.

It is useful when trust crosses organizational boundaries and only the minimum necessary information should be disclosed.

If someone needs to know whether you are legally allowed to drive, you should not have to reveal your salary, bank balance, and employment history.

You prove only the fact that is required.

A ModelAttestation binds an AI agent to an approved model, prompt, tools, or configuration before execution.

It allows trust decisions to consider not only the identity of an AI agent, but also the approved configuration under which it is operating.

Knowing the employee's identity is not always enough.

For some jobs, you also need proof that the employee is using approved equipment, following the approved procedure, and working under the correct certification.

The Recognition Graph represents direct trust and recognition relationships between Sovereigns.

As more independent domains are connected, the Recognition Graph provides a way to understand the topology of those trust relationships.

Think of a map showing which countries, companies, or institutions have formal recognition agreements with each other.

The map shows the relationships. It does not automatically make trust transitive.

The Connectome is an observability view derived from recognition relationships.

It helps operators and architects understand how trust domains are connected.

The Connectome is for visibility and analysis rather than enforcement.

It can help answer questions such as who recognizes whom, which domains are isolated, where major trust dependencies exist, and where a recognition relationship changed.

Think of a transport map.

The map does not control the vehicles. It helps you understand how the network is connected.

A PolicyManifest is Genesis Mesh network or runtime configuration policy.

It should not be confused with a BoundaryPolicy.

PolicyManifest controls aspects of how the Genesis Mesh environment operates.

BoundaryPolicy controls whether a specific requested action should be allowed.

Think of the difference between the operating rules for how a government department itself is configured and the laws used to decide whether a citizen's request is allowed.

They are both policies, but they apply at different layers.

Canonical JSON is a deterministic representation of JSON data used for signing and verification.

Different systems must produce the same exact byte representation before cryptographic signatures can be verified reliably.

Genesis Mesh uses signed artifacts across implementations and SDKs.

Canonical JSON ensures that two systems agree on exactly what was signed.

Two contracts may contain the same words but use different spacing, ordering, or formatting.

A human may consider them equivalent. A digital signature works on exact bytes.

Canonical JSON makes sure everyone writes the document in exactly the same form before signing it.