Core Concepts

This page introduces the key abstractions you will work with when integrating MeshQu.

​

Decision boundary

The decision boundary is the moment a system outcome becomes irreversible — execution, settlement, release, or approval. MeshQu is designed to sit at the decision boundary: your application calls it before (or after) that moment and receives a governed verdict.

​

Decision context

A decision context is the payload you send to MeshQu describing what is about to happen. It contains:

​

Policy

A policy is a named, versioned governance configuration that MeshQu evaluates against incoming decision contexts. Policies have:

• A unique code (human-readable identifier).
• A shadow_mode flag: when enabled, DENY decisions are downgraded to ALERT for observation.
• One or more versions. Only the active version is used during evaluation.

You manage policies via the API or the MeshQu Console.

​

Policy groups

Policies can be organised into policy groups for batch management. A decision context may be evaluated against all policies in a group.

​

Decision

Every evaluation returns a decision: The decision is advisory. Your application decides what to do with it — MeshQu does not block or allow operations on its own.

​

Decision receipt

An evaluation returns an unsigned preview with an integrity_hash; it does not record a Decision Receipt. Calling POST /v1/decisions/record stores the decision and returns a receipt. Production receipts are signed with Ed25519. An auditor verifies a signed receipt by recomputing its integrity hash and checking its version-specific signature against an independently trusted public key. The signature_kid identifies the signing key. See the Receipt Reference for the field contract.

​

Actor

An actor identifies who or what triggered a decision — a human reviewer, an automated system, or a service account. Actors are optional but strongly recommended for workflows where audit trails must name a responsible party. See the Actor Attribution guide for patterns, PII considerations, and trust model details.

​

Conditional rules

Rules can include an optional when clause for conditional applicability. A rule with when is only evaluated when the clause matches the decision context — otherwise it returns NA (not applicable) and does not affect the outcome. NA rules still appear on the decision receipt with a human-readable reason recording that the rule was considered and why it didn’t apply. That record is stored on the receipt but is not itself bound into the integrity hash — see What Is and Isn’t Bound (§14). Supported operators: Combinators nest arbitrarily: { "all": [{ "field": "region", "in": ["EU", "UK"] }, { "field": "amount", "exists": true }] }. See the API Reference for the full when syntax in policy creation.

​

Violation

When a policy does not pass, it produces one or more violations. Each violation includes:

• rule_code — which rule raised it.
• reason_code — a structured code for programmatic aggregation (e.g., FIELD_MISSING, VALUE_ABOVE_MAX).
• reason — a human-readable explanation.
• severity — how serious the violation is.

​

Decision (recorded)

A decision is a persisted evaluation result. You create one by calling /v1/decisions/record with an idempotency_key. Recorded decisions support:

• Retrieval by ID or listing with filters.
• Replay for audit verification.
• Linking to alerts.
• Grouping into decision chains.

​

Decision outcome

A decision outcome captures what happened after a verdict. For example, a REVIEW decision might be accepted or overridden by a human reviewer. One outcome per decision. Immutable once recorded. Included on individual decision retrieval.

​

Decision chain

A decision chain is an ordered group of decision receipts that together prove a governed outcome across multiple steps. Chains enable workflow traceability — instead of a bag of individual receipts, a regulator or auditor sees an ordered, parent-linked structure from trigger to outcome. Each step in a chain is a full cryptographic receipt (integrity hash + Ed25519 signature + optional Rekor anchor). The chain provides queryable grouping and ordering — it does not weaken the proof. Key properties:

• Steps are ordered by chain_step (1-based, unique per chain).
• Each step may reference a parent_decision_id for causal lineage.
• Chain membership is declared at record time and is immutable.
• Steps can come from automated evaluation or manual form review.
• The verification endpoint checks each receipt’s integrity and reports structural warnings (gaps, parent linkage).

Example: AML workflow Query GET /v1/decisions?chain_id=... returns all three steps in order. The verification endpoint confirms each receipt is individually sound. See the Decision Chains guide for integration patterns and the API Reference for endpoint details.

​

Alert

An alert is raised when notable conditions are detected (e.g. a critical policy failure). Alerts have a severity (low, medium, high, critical) and can be acknowledged. You can subscribe to alert webhooks for real-time notification.

​

Tenant

Authenticated tenant-scoped API calls require X-MeshQu-Tenant-Id, and the API key must be authorised for that tenant. Public receipt, chain, and form endpoints use resource identifiers instead; see Authentication.

​

Implemented capabilities

• Deterministic policy evaluation
• Policy snapshots protected from ordinary application updates and deletes
• Idempotent decision recording
• Tenant-isolated data
• Replayable audit trail

The Trust Model explains the limits of the cryptographic and storage claims. Service and support commitments depend on the deployment agreement.

​

What MeshQu is not

• Not a rules engine you embed. MeshQu is a standalone service. Your application calls it over HTTP.
• Not an execution layer. MeshQu returns a verdict. It never blocks, allows, or modifies operations on its own.
• Not a permissions system. MeshQu does not manage authentication or resource access. Use it alongside your existing IAM.
• Not a real-time data feed. MeshQu evaluates the context you send. It does not subscribe to market data or external sources.
• Not a scoring or risk engine. MeshQu evaluates decisions against policy. It does not generate risk scores or predictions.
• Not an explainability tool. MeshQu proves policy compliance. Model explainability is a separate concern.

​

Explicit non-goals

MeshQu intentionally does not:

• Generate risk scores or predictions.
• Subscribe to external data feeds.
• Manage user authentication or authorization.
• Explain upstream model behaviour.

These are out of scope by design, not missing features.

​

How auditors use MeshQu

1. Request a decision by ID.
2. Replay the decision against the original policy snapshot.
3. Verify integrity hashes to confirm the verdict has not been altered.
4. If the receipt is signed, verify the Ed25519 signature using the public key.
5. Confirm the policy snapshot and timestamp match expectations.

No access to application code or models is required.

​

Decision lifecycle

1. Build context — your application assembles a decision context (type, fields, metadata, evidence).
2. Evaluate or record — call /v1/decisions/evaluate for an unsigned preview, or /v1/decisions/record to evaluate and persist a signed Decision Receipt.
3. Receive verdict — both endpoints return ALLOW, REVIEW, DENY, or ALERT; only record returns a signed receipt.
4. Act — your application decides whether to proceed, queue, or block.
5. Verify later — replay a recorded decision or verify its receipt independently.

​

Evaluate vs Record

​

Example: blocking a trade and proving it later

1. Order service reaches the decision boundary.
2. Application calls evaluate with the trade context.
3. MeshQu returns DENY with a policy snapshot hash.
4. Application blocks execution and surfaces violations.
5. Decision is recorded with an idempotency key.
6. Six months later, an auditor replays the decision and verifies integrity hashes match.

No application code or model access is required.

​

How these fit together

---

Next: API Reference — full endpoint listing.