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.

A Governed Action is the complete pattern:

ask for a decision
      ↓
act only when allowed
      ↓
record success or failure
      ↓
submit execution evidence

It combines authorization and evidence into one operational pattern.

A regulated maintenance process may require approval before work, work performed only after approval, and a signed completion record afterwards.

The action is governed from request through completion.

A MembershipAttestation is a signed identity and authorization record.

It can describe a person, vendor, product team, workload, service, or another subject.

Its claims can include capabilities, associated applications, organizational membership, or other scoped attributes.

It can also be revoked.

The MembershipAttestation establishes the trusted identity basis for an authorization decision.

Think of an official company badge.

It proves who the person is and may also show their role, department, and which areas they are allowed to access.

A ContextRecord is the normalized description of the requested action.

It can include information such as requested operation, target resource, environment, owner, duration, application, subscription, or other relevant metadata.

The ContextRecord tells Genesis Mesh:

What exactly is being requested?

Think of an official application form.

The identity tells the authority who you are.

The form tells the authority what you are asking for.

A BoundaryPolicy is a signed and versioned policy that defines the rules for allowing or denying an action.

Examples of rules include a required owner, an allowed resource, a maximum value, an approved environment, or an allowed capability.

The BoundaryPolicy expresses the governance rules applied to a requested action.

Think of the written rules used by an organization to decide whether a request is acceptable.

A Gate is one specific policy check inside a BoundaryPolicy.

Examples:

resource must be approved
requested duration must be below a limit
environment must be allowed
identity must contain a required claim

A policy can contain several Gates.

Each Gate answers one focused question.

Think of an airport security process.

One checkpoint validates the ticket, another checks identity, and another checks baggage.

Each checkpoint has a specific purpose.

The Gate Registry is the trusted set of Gate implementations that the Network Authority is allowed to execute.

Policies can configure approved Gate types rather than supplying arbitrary executable code.

The Gate Registry separates trusted implementation from configurable policy.

A regulator may publish a list of approved inspection methods.

A local policy can choose which inspections apply, but it cannot invent an untrusted inspection procedure and run arbitrary code.

In Observe Mode, policy rules are evaluated and violations can be recorded without blocking the action.

Observe Mode is useful when introducing a new rule or onboarding an existing environment.

It allows teams to understand the impact of a policy before making it mandatory.

A city may introduce a new traffic rule with an initial warning period.

The system records violations, but drivers are not yet penalized.

In Enforce Mode, policy failures affect the final authorization decision.

A failing rule can cause the requested action to be denied.

Enforce Mode is used when the policy is ready to become mandatory.

The warning period is over.

The same traffic rule is now actively enforced.

The BoundaryEngine evaluates the request against identity, policy, and configured Gates.

It is the decision-processing component that turns:

identity + request + rules

into an authorization result.

Think of the official reviewing an application against the relevant rules and checking each required condition.

A BoundaryDecision is the signed ALLOW or DENY result produced for a specific requested action.

It is the authorization result consumed by the system that wants to perform the action.

DENY  → do not proceed
ALLOW → action may proceed

Think of a signed permit.

It does not perform the work itself. It officially states whether the work is authorized.

ALLOW and DENY are the outcomes a calling system acts on. The Genesis Mesh glossary also records the Network Authority policy engine's verdict as one of allow, block, escalate, or warn.

A PolicyBinding records exactly which policy version and policy evaluation contributed to a decision.

It makes old decisions understandable even after policies change.

If a decision was made two years ago, an auditor should judge it against the law that was active at that time, not the law that exists today.

PolicyBinding records that connection.

An AttestationBinding records exactly which attestation was used when a decision was made.

It can preserve information about the subject, issuer, and revocation state that formed the identity basis of the decision.

It makes the decision auditable later.

A reviewer can see not only that an action was allowed, but which trusted identity statement was used.

Think of an approval document that records the exact ID card or professional certificate that was checked before approval was granted.

A JustificationProof provides signed evidence explaining how the decision was reached.

It can include ordered Gate evaluations and their outcomes.

It answers:

Why was this action allowed or denied?

Instead of receiving only:

Approved.

you receive:

Approved because identity was valid, resource ownership matched, requested scope was permitted, and all required controls passed.

The Executor Identity represents the trusted system that performs an approved action.

The Executor Key signs the resulting ExecutionEvidence.

It allows Genesis Mesh to prove which trusted system actually carried out the action.

An approval says the work may happen.

The contractor's signed completion record says which authorized contractor actually performed it.

ExecutionEvidence is a signed record produced after an approved action is executed.

It records what actually happened.

For example:

decision: ALLOW
requested action: update resource
execution result: success
executor: controller-01
resource: resource-123
time: ...

A BoundaryDecision proves permission.

ExecutionEvidence proves execution.

These are deliberately separate.

A building permit proves construction was authorized.

The completion certificate proves the work was actually carried out.

The Execution Recorder creates and signs ExecutionEvidence produced by an executor.

It helps maintain the correct decision and resource history.

It connects the actual execution result back into the Genesis Mesh evidence model.

Think of a system that automatically creates the official completion record after an authorized job has been performed.

The Evidence Store keeps decision and execution history for later verification and audit.

It stores governance and execution metadata, not sensitive secret values.

It provides the historical record required to reconstruct what happened.

Think of an official archive where signed decisions and execution records are preserved so they can be reviewed later.

A Resource ID is a stable identifier for the governed resource associated with evidence.

It allows Genesis Mesh to group the history of one resource across many decisions and executions.

Think of a case number or property registration number that lets an auditor find every event related to the same object.

A Resource Chain is the ordered, tamper-evident execution history for one governed resource.

It can show the lifecycle of the same resource across multiple actions.

created
   ↓
updated
   ↓
rotated
   ↓
revoked
   ↓
removed

Think of the complete maintenance history for one aircraft.

Every inspection, repair, replacement, and retirement event belongs to the same asset history.

The Evidence Chain or Store Chain is the hash-linked history of evidence records.

It makes missing, reordered, or modified records detectable.

The Resource Chain organizes history around a resource.

The Evidence Chain protects the integrity of the evidence store itself.

Imagine an official register where every page contains a fingerprint of the previous page.

Changing or removing an older page breaks the chain and becomes detectable.

A RetentionCheckpoint is a signed proof left when old evidence is legitimately removed under retention rules.

It allows evidence retention policies to be applied without making the remaining history unverifiable.

An archive may legally destroy old files after a retention period.

Before destruction, it records an official signed inventory proving what existed and where the historical boundary now begins.

Revocation withdraws trust that was previously granted.

It can apply to identities, attestations, certificates, or other trust artifacts.

Revocation is one of the main ways Genesis Mesh ensures that trust is not permanent by default.

Future actions can be denied after trust is withdrawn.

An employee badge may still have six months before its printed expiry date.

If the employee leaves today, the organization revokes the badge immediately.

The Metadata Guard protects the governance and evidence layer from receiving obvious secret material.

Genesis Mesh should receive identifiers, metadata, versions, timestamps, and evidence, not raw secret values.

It helps maintain a clean separation between governance data and protected secret material.

An audit report should contain:

Safe deposit box 123 was opened by authorized employee 45 at 10:15.

It should not contain the contents of the safe deposit box.

A Genesis Mesh SDK provides application code with a supported way to interact with the Network Authority and Genesis Mesh data structures.

It can handle areas such as requests, signing, verification, policy evaluation, evidence submission, and related client-side operations.

Applications and controllers can use the SDK instead of manually implementing the Network Authority protocol and signing behavior.

Instead of every company building its own custom interface to a government service, the government provides an official client library that follows the required forms and procedures correctly.

Reconciliation compares recorded Genesis Mesh state with the observed state of the real system.

It can identify cases such as unmanaged resources, drift, resources removed outside the governed flow, or resources that still exist after trust was revoked.

Preventive controls govern actions that go through Genesis Mesh.

Reconciliation provides detective control for things that happened outside the expected path.

A company's accounting system may approve every purchase order.

Reconciliation later compares the purchase records with the actual bank transactions to find anything that bypassed the approved process.

A Signer is the abstraction used to create Genesis Mesh signatures without requiring private keys to be embedded directly in application code.

The signing implementation can use a protected key service, HSM, or another secure signing mechanism.

It separates the need to sign from where the private key is actually stored.

An employee can request an official company stamp without carrying the master stamp around in their pocket.

The secure signing service keeps the sensitive signing material protected.