Changelog

Documentation Index

Fetch the complete documentation index at: https://docs.meshqu.com/llms.txt

Use this file to discover all available pages before exploring further.

MeshQu follows Semantic Versioning. The current API version is v1.9.0.

​

Versioning policy

• Major (v2.x): Breaking changes to request/response contracts or authentication. Announced with a migration guide and deprecation period.
• Minor (v1.2): New endpoints, fields, or features. Backwards-compatible.
• Patch (v1.1.1): Bug fixes and performance improvements. No contract changes.

​

Stability guarantees

• Existing response fields are never removed or renamed within a major version.
• New optional fields may be added to responses at any time — clients should ignore unknown fields.
• Webhook payload schemas follow the same policy.

​

API version header

All endpoints are prefixed with /v1. When a new major version is released, the previous version will remain available for a documented deprecation period.

---

​

v1.9.0

Tenant Governance Settings

• New GET /v1/settings and PATCH /v1/settings endpoints for tenant-level governance configuration.
• Includes maker-checker toggle controlling whether policy versions require an independent ratifier before becoming active.

---

​

v1.8.0

Human Decision Capture (Forms)

• New Forms surface for capturing structured human decisions that produce receipts identical in shape to programmatic decisions.
• Endpoints: POST /v1/forms, GET /v1/forms, GET /v1/forms/:formId, PATCH /v1/forms/:formId, DELETE /v1/forms/:formId.
• Form schemas and API contracts are introspectable: GET /v1/forms/:formId/schema, GET /v1/forms/:formId/api-contract.
• Submissions: POST /v1/forms/:formId/submit returns a decision receipt; retrieve later via GET /v1/forms/:formId/receipts/:decisionId.

---

​

v1.7.0

Policy v2 Lifecycle (Submit / Reject / Recall)

• Draft policy versions now move through an explicit lifecycle:
  • POST /v1/policies/:id/versions/:version/submit — submit a draft for ratification.
  • POST /v1/policies/:id/versions/:version/reject — reject a submitted draft.
  • POST /v1/policies/:id/versions/:version/recall — recall a submitted draft back to draft state.
• Additional draft-version endpoints: GET /v1/policies/:id/versions/:version, PATCH /v1/policies/:id/versions/:version, DELETE /v1/policies/:id/versions/:version.
• New GET /v1/policies/:id/decisions — list all decisions evaluated against a given policy.

---

​

v1.6.0

Receipt Schema v2 + Approval Lineage

• New top-level fields on decision receipts:
  • receipt_schema_version — explicit schema version marker.
  • policy_snapshot_digest — canonical SHA-256 of the bound policy snapshot.
  • evidence_manifest_digest — canonical SHA-256 of the evidence manifest, when present.
• Policy Approval Receipts — cryptographic ratifier signatures on the policy version that governed a decision. The offline verifier now accepts ratifier and custodian public-key sets as additional trust roots.
• All v1 receipts remain verifiable indefinitely — schema v2 fields are additive.

---

​

v1.5.0

Public Verification Surface

• New JWKS endpoint: GET /v1/.well-known/signing-keys — versioned public signing keys for offline receipt verification.
• New public, unauthenticated endpoints (callers do not need an API key):
  • GET /v1/receipts/:decisionId — fetch a signed decision receipt.
  • GET /v1/receipts/:decisionId/bundle — download the full Verification Bundle.
  • GET /v1/chains/:chainId/verify — verify a chain proof.
  • GET /v1/chains/:chainId/seal — read a chain seal.
  • GET /v1/chains/:chainId/bundle — download a chain Verification Bundle.
• Verification Bundles — self-contained, offline-verifiable archives covering 8 sub-claims under a digest-of-digests manifest (receipt, policy snapshot, chain proofs, transparency proof, trust roots, canonicalisation).

---

​

v1.4.0

Actor Attribution

• POST /v1/decisions/record now accepts an optional top-level actor object: id, type, role, authority, display_name.
• actor.id is included in the integrity hash and cryptographically bound to every receipt.
• Other actor fields are stored for audit display.
• Backward compatible: actor is optional. If omitted and context.metadata.actor_id is present, the API falls back to that value. When actor.id is supplied, it takes precedence.
• New actor optional parameter on client.record() in the TypeScript SDK.
• Decision chain steps can now carry per-step actor attribution, enabling multi-actor chain audit trails.

---

​

v1.3.0

Structured Violation Reason Codes

• Every violation now includes a reason_code field — a structured code for programmatic aggregation without text parsing.
• 17 reason codes across all rule types: presence (FIELD_MISSING, FIELD_FORBIDDEN, FIELD_TOO_SHORT), temporal (DATE_EXPIRED, DATE_INVALID, etc.), threshold (VALUE_ABOVE_MAX, VALUE_BELOW_MIN, etc.), and list (VALUE_NOT_ALLOWED, VALUE_FORBIDDEN).
• New ReasonCode type exported from @meshqu/types and re-exported from @meshqu/client.
• Backwards compatible: reason_code is a new required field on violations. Existing reason strings are unchanged.
• Replay note: New receipts have different integrity hashes than pre-reason_code receipts due to the additional field. Pre-migration receipts remain verifiable against their stored hash.

Decision Outcomes

• New POST /v1/decisions/:id/outcome endpoint to capture what happened after a verdict.
• Five outcome statuses: accepted, overridden, escalated, expired, abandoned.
• One outcome per decision (409 on duplicate). Immutable after insert.
• Outcomes included on GET /v1/decisions/:id response.
• New recordOutcome() method in the TypeScript SDK.

Violation Analytics & Identifier Stability

• Violations denormalized into queryable table at write time (analytics projection, not source of truth).
• GET /v1/decisions now accepts correlation_id query parameter.
• Policy rules accept optional replaces_rule_code for advisory lineage tracking.

​

v1.2.0

Conditional Rule Applicability (When Gating)

• Added optional when clause on policy rules — rules are only evaluated when the clause matches the decision context.
• Non-matching rules return NA (not applicable) with a human-readable reason on the decision receipt.
• New optional fields on EvaluationResult: rules_na (count) and na_rules (details).
• Supported when operators: equals, in, exists, with all/any combinators for nested logic.
• Snapshot hash includes when clauses (backward compatible — existing hashes unchanged).

Receipt Signing

• Decision receipts are now signed with Ed25519 when a signing key is configured.
• Receipts include signature, signature_kid, and signature_algorithm fields.
• Auditors can verify receipts using the public key alone — no shared secret needed.

Security & Infrastructure

• Encryption key versioning with rotation support and legacy fallback.
• Rate limiting upgraded to shared state across API replicas.

​

v1.1.0

• Added policy groups (CRUD + listing policies within a group).
• Added alert webhook subscriptions with HMAC-signed delivery.
• Added webhook delivery history and statistics endpoints.
• Added decision SSE stream (GET /v1/decisions/stream).
• Added audit log verification (POST /v1/audit-log/verify).
• Added API key naming (key_name) for audit attribution.
• Added advisory mode for policies.
• Added two-tier rate limiting (pre-auth + post-auth).

​

v1.0.1

Production hardening release. All fixes are backwards-compatible at the HTTP layer.

• SDK apiKey configuration is now required (throws a clear error if missing).
• idempotency_key is now required when recording decisions (no longer auto-generated).
• Added dryRun() as a semantic alias for evaluate().
• Recorded decisions now capture audit attribution (api_key_id, api_key_name).
• Backend infrastructure failures now return 503 Service Unavailable with retry_after instead of 500.
• Production authentication hardening improvements.

​

v1.0.0

• Initial release.
• Policy CRUD with immutable versioning.
• Decision evaluation (dry-run) and recording (persisted).
• Decision replay for audit verification.
• Alert listing and acknowledgement.
• API key management with scoped access.
• Audit event listing.
• OpenAPI 3.0 spec and Swagger UI.