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 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.