MeshQu Developer Docs

MeshQu is currently available for research, evaluation and design-partner deployments. Production availability and support commitments are agreed per engagement. To request access, contact contact@meshqu.com.

Audience: These docs are for engineers integrating MeshQu into regulated or audit-sensitive systems, and for security, risk, and audit teams validating its behaviour. MeshQu is not intended for feature flagging, application permissions, or consumer-facing rule evaluation. MeshQu provides governance infrastructure for automated and AI-assisted decisions that must follow explicit policy. Integrate MeshQu into your application to evaluate transactions, operations, or events against configurable policies and receive structured decisions.

What a Decision Receipt is

A Decision Receipt is a signed, replayable record of how a consequential decision was made, created at the moment it happens and independently verifiable afterwards. It records the policy in force, relevant decision context, the outcome and the integrity information needed to determine later whether the signed record has changed. See the Receipt Reference for the field-level contract, and Verifying Offline to check one yourself. New to MeshQu? Start with what a Decision Receipt is — the public overview, written for a reader who has not yet decided to integrate.

Mental model: MeshQu sits at the decision boundary. You send context, it returns a governed verdict and a verifiable receipt. You own enforcement.

Why MeshQu exists

Automated and AI-assisted systems make decisions constantly. Few can prove those decisions followed policy at the moment they mattered. Logs show what happened. They do not prove policy compliance. MeshQu closes that gap. It makes decisions governable, replayable, and independently verifiable — at the decision boundary. Key concepts: Decision context · Policy · Decision · Alert

What MeshQu does

You send a decision context (the data describing what is about to happen). MeshQu evaluates it against your active policies and returns a decision: ALLOW, REVIEW, DENY, or ALERT, along with any violations. Your application decides what to do with the decision. MeshQu does not block or allow anything on its own — it provides the verdict and your code acts on it.

If you remember one thing: MeshQu is called at the decision boundary, not after.

Advisory by design: MeshQu returns a governed verdict. Enforcement always remains in your system.

curl -X POST https://api.meshqu.com/v1/decisions/evaluate \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "X-MeshQu-Tenant-Id: YOUR_TENANT_ID" \
  -H "Content-Type: application/json" \
  -d '{
    "context": {
      "decision_type": "trade_execution",
      "fields": { "account_id": "ACC-001", "instrument": "AAPL", "quantity": 100 }
    }
  }'

{
  "result": {
    "decision": "ALLOW",
    "violations": [],
    "rules_evaluated": 3
  }
}

MeshQu is advisory by design. It returns a verdict — your application decides whether to proceed, queue, or block. MeshQu never enforces outcomes on its own.

Evaluate vs Record — evaluate is fast and records no decision; resolving the active policies may still append one row to the tenant’s append-only policy_snapshots table, and a repeat call resolving to the same policies appends nothing. record persists the decision itself for audit. Most production systems use evaluate on the hot path and record for compliance-critical actions. See Evaluate vs Record.

What happens after you integrate

Your system calls MeshQu before or after the decision boundary — the moment an outcome becomes irreversible.
MeshQu evaluates the context against your active policies and returns a verdict — and, when you call record, a signed Decision Receipt.
Your code decides how to act — proceed, queue for review, or block.
Auditors can independently replay and verify any recorded decision later.

Key capabilities

Capability	Description
Policy evaluation	Evaluate a context against one or many policies in a single call.
Decision recording	Persist evaluation results for audit and compliance.
Idempotent recording	Supply an `idempotency_key` to safely retry without duplicate records.
Alert webhooks	Receive real-time notifications when alerts are raised.
Multi-tenant	Every request is scoped to a tenant via the `X-MeshQu-Tenant-Id` header.
Scoped API keys	Fine-grained access control with per-key scopes.
Advisory mode	Safely test new policies in production; violations generate alerts but do not block traffic.

Quick links

Quickstart — make your first API call in minutes.
Authentication — how API keys and scopes work.
API Reference — full endpoint listing.
TypeScript SDK — install and use the client library.
Integration Patterns — common ways to wire MeshQu into your stack.

Base URLs

Environment	URL
Production	`https://api.meshqu.com`
Staging	`https://api-staging.meshqu.com`
Local dev	`http://localhost:3002`

All endpoints are prefixed with /v1.

OpenAPI

A machine-readable OpenAPI 3.1 spec is available at:

GET /openapi.json

Interactive Swagger UI is available at /docs when enabled.

Getting Started

Concepts

API Reference

SDK

Guides

Recipes

Security

Meta

What a Decision Receipt is

Why MeshQu exists

What MeshQu does

What happens after you integrate

Key capabilities

Quick links

Base URLs

OpenAPI

​What a Decision Receipt is

​Why MeshQu exists

​What MeshQu does

​What happens after you integrate

​Key capabilities

​Quick links

​Base URLs

​OpenAPI

What a Decision Receipt is

Why MeshQu exists

What MeshQu does

What happens after you integrate

Key capabilities

Quick links

Base URLs

OpenAPI