DeltaX Preflight
OfficialChecks a proposed agent or CI/CD action against owner-controlled policy and independently supplied evidence, returning a deterministic verdict without executing or choosing anything.
preflight_check— validate a decision (1–100 candidates), policy, and evidence in one call; returns a status (PASS_SINGLE,SELECTION_REQUIRED,REFUSE, orEVIDENCE_REQUIRED), candidate/admissible/rejected/unproven counts, per-candidate results, admissible IDs, and a SHA-256 receipt hashing decision, policy, evidence, and result.Returns a local
handoffobject only forSELECTION_REQUIRED(otherwisenull); it is explicitly not an API request and grants no execution authority.preflight_hash_decision— validate a decision and return its canonical SHA-256 digest so an evidence producer can bind facts to the exact proposal it reviewed.preflight_hash_policy— validate a policy and return its canonical SHA-256 digest for pinning owner rules outside an untrusted proposal.Evaluates hard constraints using
eq,in,lte,gte, andexistsover candidate or context facts; missing facts stay unproven rather than passing.All three tools are read-only, idempotent, and closed-world: no network calls, no account or API key, and invalid input returns a tool error with no partial report.
Does not authenticate caller-supplied facts, rank or select among admissible options, execute actions, filter prompts, or call DeltaX Evaluate.
Provides a GitHub Action and required pull request workflow check that validates proposed agent actions against owner-controlled policy and evidence before merge, blocking when evidence is missing or selection remains open.
DeltaX Preflight
Check an agent's proposed next step before a pull request can merge.
DeltaX Preflight checks proposed actions against owner-controlled rules and evidence. Use the GitHub Action as a required workflow check, or connect the local MCP server to check proposals from an agent. Both use the same deterministic validator. No DeltaX account or API key is needed.
Try the live demo — no download, account or API key
Install the command-line package
Requires Node.js 20 or later. Install the core validator with:
npm install --global deltax-preflight
deltax-preflight-try --example
deltax-preflight-init my-check
deltax-preflight my-check/decision.json --policy my-check/policy.json --evidence my-check/evidence.jsonThe sample returns SELECTION_REQUIRED. The starter files return EVIDENCE_REQUIRED until you provide trusted facts. Both results are intentional and select or execute nothing. The npm package also exports the validator and bounded Evaluate bridge for JavaScript integrations. The GitHub Action and optional MCP server have separate setup instructions; the npm package does not install the MCP server.
Keep policy and evidence under the workflow owner's control. Preflight checks the supplied facts; it does not establish their truth, choose among multiple allowed options, or execute actions. To block a GitHub merge, configure the workflow check as required. The MCP server evaluates its caller's documents; the surrounding application controls trust and enforcement. DeltaX Evaluate is an optional, separate integration.
Related MCP server: contextboundary-gw
When a reviewed action changes
An agent proposes inspect_change with scope: local. The owner's reviewed manifest covers that exact payload. If the agent keeps the same action ID but changes the scope to public, that review no longer supplies evidence for the new proposal.
Try the live visual walkthrough: four selectable scenes, synthetic inputs, and precomputed results from the real validator. No download or API key is needed. You can also run it offline.
Proposal in the example | Preflight result | What remains |
Reviewed local inspection plus a forbidden publish option |
| Inspection is the one admissible option; nothing is executed. |
Same inspection ID, changed payload |
| Obtain evidence for the changed proposal. |
Two exact, reviewed local options |
| A human or separately authorized system must choose. |
Only the forbidden publish option |
| No admissible option remains. |
These synthetic scenarios use the owner-reviewed gate fixtures. The independent example pull requests show actual GitHub checks for the first three outcomes.
This is a public preview. The core validator has no runtime dependencies and works offline. ADR 0002 defines the local protocol; ADR 0003 defines the bounded handoff. The R&D issue and issue evidence record the earlier prototype checks and their limits.
Try it without making files
Requires Git and Node.js 20 or later. No account or installation step is needed:
git clone https://github.com/DeltaX-Public/deltax-preflight.git
cd deltax-preflight
node bin/try.mjs --example
node bin/try.mjsThe first command shows an immediate synthetic result. The second asks for your options, hard requirements, and yes/no/unknown facts. It reports which options satisfy those requirements and stops if selection remains open or evidence is missing. This is a self-reported decision worksheet, not an independently verified workflow gate. It selects and executes nothing. To save your answers as versioned inputs, run node bin/try.mjs --save my-check instead of the second command. Reopen the saved result with node bin/try.mjs --replay my-check; your option names remain visible. Verify the facts before using any saved worksheet as an automation input.
The example shows the distinction in a few seconds:
PREFLIGHT (based on synthetic example): SELECTION_REQUIRED
- Review locally: admissible
- Compare evidence: admissible
- Publish now: rejected
More than one option meets the stated requirements. Selection remains open.Use it in a workflow
For a working GitHub pull request gate, run node bin/install-github.mjs /path/to/your-repo from this checkout. It adds one workflow and three example files without overwriting existing files. The workflow checks proposed agent actions against an owner-reviewed list; it uses the base branch for its policy and evidence source, treats the pull request proposal as data, and pins this checkout's Preflight commit and policy hash. Review the files and commit them to your repository's default branch before opening a proposal pull request. The complete recipe explains the results and how to require the check before merge. The check does not run any proposed action.
The independent example repository ran this recipe on GitHub: one allowed action passed and merged, while a changed payload stopped for evidence and two allowed actions stopped for selection. Its main branch requires the preflight check.
For an automated check, policy must come from the workflow owner and facts from a source authorized to assert them. If you need file templates, run:
node bin/init.mjs my-checkThis creates decision.json, policy.json, evidence.json, and a short guide in my-check/. The first run deliberately returns EVIDENCE_REQUIRED: you must replace the empty facts with evidence from a source you trust. You can start from those valid files without learning the JSON structure first. You still need to decide which rules apply and who can assert the facts.
In plain terms: the decision lists options, the policy states requirements, and the evidence contains checked facts about each option. Keep policy and evidence under the control of people or systems authorized to provide them.
The full examples run without setup:
node bin/preflight.mjs examples/ci-deploy.json \
--policy examples/ci-policy.json \
--evidence examples/ci-evidence.json
node bin/preflight.mjs --hash-policy examples/ci-policy.json
node bin/preflight.mjs --hash-decision examples/ci-deploy.json
node --test
node bin/demo-handoff.mjsThe first example intentionally exits with code 2: two valid options remain, so selection is still needed. That is a successful demonstration of the decision boundary, though a shell configured to stop on nonzero exits will pause there.
The decision path may be - for standard input. Use --json to emit { "result": ..., "handoff": ... }. For a pinned policy, add --expect-policy-sha256 <hash>. Each input is limited to 1 MiB by the CLI and Action.
The decision, policy, and evidence files have separate JSON Schemas. The examples include a CI deployment proposal and an agent action proposal, each with matching policy and evidence files. Candidate IDs and payloads express what is proposed. Only evidence facts are checked against policy.
Local MCP server
The optional MCP adapter exposes the same validator and canonical decision/policy hash helpers over local stdio. Install its separate dependencies with npm ci --prefix mcp --ignore-scripts, then configure your MCP host to launch node /absolute/path/to/deltax-preflight/mcp/bin/server.mjs. The adapter returns the existing result and handoff unchanged. It does not call Evaluate, select or execute candidates, authenticate caller-supplied facts, or add dependencies to the core validator. See the adapter guide for tool arguments, client configuration, and tests.
An optional Glama-managed container deployment runs through Glama's proxy and infrastructure. Review that data boundary before sending policy, evidence, or candidate payloads; the local stdio setup above keeps them in the MCP host's environment.
Trust boundary
Keep policy under the workflow owner's control, separate from the actor proposing candidates. Obtain evidence from a source authorized to assert the relevant facts. The evidence producer must set decision_hash to the canonical hash of the exact proposal it checked; --hash-decision computes that value. A changed proposal is rejected even when candidate IDs stay the same. The evidence.source string identifies that source for records but does not authenticate it. Preflight cannot establish that supplied facts are true. Its receipt hashes the decision, policy, evidence, and result separately; hashes detect changed content but do not grant authority to act.
The GitHub Action requires expected_policy_sha256. Calculate it with --hash-policy and pin it in a protected workflow. A policy file from a pull request checkout is not independently trusted merely because its hash matches a value the same pull request can change. The Action also needs a trustworthy evidence producer. It does not upload the envelope or use network credentials.
Result states
Status | Meaning | Exit code |
| Exactly one candidate is proven admissible; all others are rejected. Nothing is executed. | 0 |
| Multiple candidates are proven admissible. Local validation stops without choosing one. | 2 |
| No candidate is admissible, and none is unproven. | 3 |
| At least one candidate is unproven because evidence is missing or has the wrong type. No handoff is produced. | 4 |
Malformed input, unrecognized candidate evidence, or a policy hash mismatch exits 64. Each candidate includes per-constraint pass, fail, or unknown checks. A definitive failure rejects a candidate; otherwise an unknown check makes it unproven. Supported operators are eq, in, lte, gte, and exists over JSON Pointers into candidate or context evidence.
Only SELECTION_REQUIRED emits the local Evaluate handoff. It contains the original proposal, policy, evidence, admissible set, and receipt. It is not a hosted API request. Inspect and minimize it before any later network transmission. An Evaluate adapter must use the verified service contract, refuse selections outside the admissible set, and never execute a candidate on Preflight's behalf.
Bounded Evaluate bridge
The optional bridge turns a verified SELECTION_REQUIRED handoff into the fixed bounded-review request described in the DeltaX developer guide. It sends only proven admissible candidates with explicitly supplied objective and scalar context; it does not copy the full proposal, policy, or evidence into the request. The bridge accepts at most eight review candidates and refuses external candidates as selectable options. A success response must match the 2026-09-16.beta2 shape, preserve all false authority and effect flags, and select only an admissible candidate or return governed_noop_refusal.
node bin/demo-handoff.mjs runs a synthetic offline demonstration: three options enter Preflight, two survive, and a synthetic contract-valid response selects one review step. It records both receipts and the proposed, admissible, and selected IDs. This demo makes no API call and supplies no credential. Hosted access remains restricted; use an assigned client and its transport checks for any separately authorized live call. The bridge does not rank candidates or grant action authority.
GitHub Action
The Node 24 Action runs the same local validator. It requires a GitHub-hosted runner or a self-hosted runner that supports Node 24 actions. A workflow can use a reviewed commit and a policy hash pinned outside untrusted proposal changes:
steps:
- uses: actions/checkout@v4
- uses: DeltaX-Public/deltax-preflight@<reviewed-commit-sha>
with:
decision_file: path/to/decision.json
policy_file: path/to/protected-policy.json
evidence_file: path/to/trusted-evidence.json
expected_policy_sha256: <hash-from---hash-policy>The Action outputs status, admissible_count, receipt_hash, and policy_hash. It fails the job for unresolved selection, refusal, or missing evidence. The example paths only illustrate the interface: the calling workflow must actually protect its policy and evidence sources.
The proposal integration workflow demonstrates that boundary for this repository. It runs trusted action code, policy, and a reviewed candidate manifest from the pull request's base commit. It checks out the proposed decision separately as data only. The trusted evidence producer compares each candidate's exact payload with the manifest and leaves changed or unknown options unproven. The workflow has read-only repository permission and does not execute proposed code. Its policy hash is pinned in the base workflow. GitHub main branch protection requires a PR and passing preflight and test checks, including for administrators; see the positive and negative run evidence.
Migration from v1
The first prototype put constraints and candidate facts in one decision envelope. Version 2 intentionally rejects that shape. Move constraints into a policy file, facts into an evidence file, and keep only proposal payloads in the decision file. EVIDENCE_REQUIRED is a new status, and a missing exists fact is now unknown. No v1 compatibility path is enabled in the default CLI or Action.
License
DeltaX Preflight is licensed under the Apache License 2.0. This license covers this repository; it does not license the separate DeltaX Evaluate service or its internals. The core command-line package is published on npm; the optional MCP adapter remains distributed separately.
Available Tools
3 toolspreflight_checkARead-onlyIdempotent
Check concrete candidate actions against owner-controlled policy and separately obtained evidence. Returns {result, handoff}: PASS_SINGLE means one proven option, SELECTION_REQUIRED means multiple, REFUSE means none, and EVIDENCE_REQUIRED means at least one remains unproven. Handoff is null except for SELECTION_REQUIRED. Invalid documents return a tool error with no partial report.
When to use
Before an agent action or CI/CD step when a concrete proposal, owner policy, and proposal-bound evidence are available.
To identify admissible options or missing evidence.
When NOT to use
Do not use for natural-language prompt filtering or content moderation.
Do not use to rank or choose among multiple admissible options.
Do not use to authenticate supplied facts, execute actions, or call DeltaX Evaluate.
| Name | Required | Description | Default |
|---|---|---|---|
| policy | Yes | Owner-controlled Preflight v2 policy object with hard constraints over candidate or context evidence. Supported op values: eq, in, lte, gte, exists. Keep policy separate from the proposer. | |
| decision | Yes | Preflight v2 object with schema_version "2", a decision_id, context, and 1-100 candidates with unique IDs and payloads. Candidate claims are proposals, not proof. | |
| evidence | Yes | Preflight v2 evidence object from an authorized fact source. Its decision_hash must match this exact decision; missing facts remain unproven. The example source is illustrative, not authenticated. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes | The unchanged Preflight v2 validation report; it never authorizes execution. |
| handoff | Yes | The original local handoff only for SELECTION_REQUIRED; otherwise null. It is not an API request. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial behavior beyond them: a {result, handoff} return contract with all four result values enumerated, handoff null except for SELECTION_REQUIRED, and the failure mode that invalid documents produce a tool error with no partial report. It also warns that evidence must be separately obtained and that the illustrative source is not authenticated — a provenance caveat no annotation conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads purpose and return contract in the first two sentences, then uses tight labeled bullets for eligibility and exclusions. No sentence is redundant; even the failure-mode note earns its place by ruling out partial reports.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite nested objects and a three-way document contract, the description covers input provenance (policy vs. evidence vs. proposal), the verdict vocabulary, the handoff rule, and error behavior. With an output schema present, nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description adds real semantic constraints on top — that policy is owner-controlled and must stay separate from the proposer, that evidence is bound to this exact decision via decision_hash, and that missing facts stay unproven. It does not, however, restate the supported constraint ops or the 1-100 candidate limit in prose, leaving those to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (check) and precise resources (concrete candidate actions, owner-controlled policy, separately obtained evidence), plus what the outcome space looks like. The scope is narrow enough that it is clearly distinct from the preflight_hash_* siblings, which only produce hashes rather than a decision verdict.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Has explicit 'When to use', 'When NOT to use' lists with concrete triggers (before an agent action or CI/CD step; identifying admissible options or missing evidence) and explicit exclusions (not prompt filtering, not ranking/choosing, not authentication or execution, not DeltaX Evaluate). This is the full when/when-not/alternative triad.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
preflight_hash_decisionARead-onlyIdempotent
Validate a Preflight v2 decision and return {decision_hash}, its canonical SHA-256 digest. Invalid decisions return a tool error, not a hash.
When to use
Before an evidence producer binds facts to the exact proposal it checked.
When NOT to use
Do not treat the hash as proof of facts, approval of an action, or a substitute for preflight_check when policy and evidence are ready.
| Name | Required | Description | Default |
|---|---|---|---|
| decision | Yes | Preflight v2 object with schema_version "2", decision_id, context, and 1-100 unique candidate IDs with payloads. |
Output Schema
| Name | Required | Description |
|---|---|---|
| decision_hash | Yes | Canonical SHA-256 digest. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely new behavior: invalid decisions raise a tool error rather than returning a hash, and the hash is explicitly not proof of facts or approval. It does not say whether the hash is stable across formatting/key ordering, which is the one behavioral detail a caller binding facts would care about.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the verb, return value, and error semantics in two sentences, then cleanly sectioned guidance. The 'When NOT to use' bullet is dense and jargon-heavy, but it is not redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no elaboration, and the description still names the returned field and its digest algorithm. Error behavior, scope limits, and the sibling handoff are all present; nothing an agent needs in order to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter carries an inline description plus a full example, so the schema does the heavy lifting. The description adds only the 'v2 decision' framing and nothing about the nested candidate/context structure. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (validate), a specific resource (a Preflight v2 decision), and the exact return shape ({decision_hash} = canonical SHA-256 digest). It also implicitly separates itself from siblings by naming preflight_check and by the 'hash_*' pairing with preflight_hash_policy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Has explicit 'When to use' and 'When NOT to use' sections, including a named alternative (preflight_check) and the condition under which that alternative applies. The one gap is that it never contrasts with preflight_hash_policy, but the decision-vs-policy split is legible from the resource names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
preflight_hash_policyARead-onlyIdempotent
Validate a Preflight v2 policy and return {policy_hash}, its canonical SHA-256 digest. Invalid policies return a tool error, not a hash.
When to use
To pin owner-controlled rules outside an untrusted proposal.
When NOT to use
Do not treat a caller-supplied hash as proof of policy ownership. Use preflight_check to evaluate candidates once policy and evidence are ready.
| Name | Required | Description | Default |
|---|---|---|---|
| policy | Yes | Owner-controlled Preflight v2 object with schema_version "2", policy_id, and 1-100 hard constraints using eq, in, lte, gte, or exists. |
Output Schema
| Name | Required | Description |
|---|---|---|
| policy_hash | Yes | Canonical SHA-256 digest. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint, idempotency, non-destructiveness and closed-world scope, so the safety profile is covered. The description still adds real behavioral value: invalid policies raise a tool error rather than returning a hash, and it warns against trusting externally supplied hashes. Minor gap: no statement about determinism across schema-equivalent policy shapes beyond the 'canonical' wording.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded outcome sentence followed by two short scoped sections; every line either states behavior or routes to an alternative. No filler and no repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists and the description still names the returned field and the failure mode (tool error, no hash). Combined with the ownership caveat, an agent has everything needed to call it correctly in the pin-then-check workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter with 100% schema description coverage including an inline example, so the schema does the heavy lifting. The description adds only that validation is against the v2 policy structure; the constraint ops and count limits live in the schema, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb (validate) plus the resource (Preflight v2 policy) and the exact return ({policy_hash}, canonical SHA-256 digest). It also delineates the boundary against sibling preflight_check, so an agent can pick it without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' (pinning owner-controlled rules outside an untrusted proposal) and 'When NOT to use' (don't treat a caller-supplied hash as proof of ownership), with the correct alternative named — preflight_check for evaluating candidates. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v0.1.4- Changed
preflight_check5 fields changed- added
Input schema / properties / decision / examplesAdded value: +[ + { + "candidates": [ + { + "id": "review", + "payload": { + "action": "review" + } + } + ], + "context": {}, + "decision_id": "example-review", + "kind": "decision", + "schema_version": "2" + } +] - changed
Input schema / properties / evidence / descriptionPrevious value: -"Preflight v2 evidence object from an authorized fact source. Its decision_hash must match this exact decision; missing facts remain unproven."New value: +"Preflight v2 evidence object from an authorized fact source. Its decision_hash must match this exact decision; missing facts remain unproven. The example source is illustrative, not authenticated." - added
Input schema / properties / evidence / examplesAdded value: +[ + { + "candidates": [ + { + "facts": { + "approved": true + }, + "id": "review" + } + ], + "context": {}, + "decision_hash": "bc34498f36f54ad1a06b56079f41ac90d8cfd6cf6a647f812f0078b765d544f7", + "evidence_id": "example-evidence", + "kind": "evidence", + "schema_version": "2", + "source": "example-source" + } +] - changed
Input schema / properties / policy / descriptionPrevious value: -"Owner-controlled Preflight v2 policy object with hard constraints over candidate or context evidence; keep it separate from the proposer."New value: +"Owner-controlled Preflight v2 policy object with hard constraints over candidate or context evidence. Supported op values: eq, in, lte, gte, exists. Keep policy separate from the proposer." - added
Input schema / properties / policy / examplesAdded value: +[ + { + "constraints": [ + { + "id": "approved", + "op": "eq", + "path": "/approved", + "source": "candidate", + "value": true + } + ], + "kind": "policy", + "policy_id": "example-policy", + "schema_version": "2" + } +]
- Changed
preflight_hash_decision1 field changed- added
Input schema / properties / decision / examplesAdded value: +[ + { + "candidates": [ + { + "id": "review", + "payload": { + "action": "review" + } + } + ], + "context": {}, + "decision_id": "example-review", + "kind": "decision", + "schema_version": "2" + } +]
- Changed
preflight_hash_policy1 field changed- added
Input schema / properties / policy / examplesAdded value: +[ + { + "constraints": [ + { + "id": "approved", + "op": "eq", + "path": "/approved", + "source": "candidate", + "value": true + } + ], + "kind": "policy", + "policy_id": "example-policy", + "schema_version": "2" + } +]
3 tool updates
v0.1.3- Changed
preflight_check3 fields changed- added
Input schema / properties / decision / typeAdded value: +"object" - added
Input schema / properties / evidence / typeAdded value: +"object" - added
Input schema / properties / policy / typeAdded value: +"object"
- Changed
preflight_hash_decision1 field changed- added
Input schema / properties / decision / typeAdded value: +"object"
- Changed
preflight_hash_policy1 field changed- added
Input schema / properties / policy / typeAdded value: +"object"
3 tool updates
v0.1.2- Changed
preflight_check4 fields changed- changed
Input schema / properties / decision / descriptionPrevious value: -"Preflight v2 decision JSON document; the core validator checks its fields."New value: +"Preflight v2 object with schema_version \"2\", a decision_id, context, and 1-100 candidates with unique IDs and payloads. Candidate claims are proposals, not proof." - changed
Input schema / properties / evidence / descriptionPrevious value: -"Preflight v2 evidence JSON document, bound to the exact decision_hash."New value: +"Preflight v2 evidence object from an authorized fact source. Its decision_hash must match this exact decision; missing facts remain unproven." - changed
Input schema / properties / policy / descriptionPrevious value: -"Preflight v2 policy JSON document from the workflow owner."New value: +"Owner-controlled Preflight v2 policy object with hard constraints over candidate or context evidence; keep it separate from the proposer." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": false, + "properties": { + "handoff": { + "description": "The original local handoff only for SELECTION_REQUIRED; otherwise null. It is not an API request.", + "type": [ + "object", + "null" + ] + }, + "result": { + "description": "The unchanged Preflight v2 validation report; it never authorizes execution.", + "properties": { + "admissible_candidate_ids": { + "items": { + "type": "string" + }, + "type": "array" + }, + "candidates": { + "items": { + "type": "object" + }, + "type": "array" + }, + "counts": { + "properties": { + "admissible": { + "minimum": 0, + "type": "integer" + }, + "received": { + "minimum": 0, + "type": "integer" + }, + "rejected": { + "minimum": 0, + "type": "integer" + }, + "unproven": { + "minimum": 0, + "type": "integer" + } + }, + "required": [ + "received", + "admissible", + "rejected", + "unproven" + ], + "type": "object" + }, + "receipt": { + "properties": { + "algorithm": { + "const": "sha256" + }, + "decision_hash": { + "description": "Canonical SHA-256 digest.", + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "evidence_hash": { + "description": "Canonical SHA-256 digest.", + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "policy_hash": { + "description": "Canonical SHA-256 digest.", + "pattern": "^[a-f0-9]{64}$", + "type": "string" + }, + "result_hash": { + "description": "Canonical SHA-256 digest.", + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "algorithm", + "decision_hash", + "policy_hash", + "evidence_hash", + "result_hash" + ], + "type": "object" + }, + "status": { + "description": "One proven option, multiple proven options, none allowed, or missing evidence.", + "enum": [ + "PASS_SINGLE", + "SELECTION_REQUIRED", + "REFUSE", + "EVIDENCE_REQUIRED" + ] + } + }, + "required": [ + "status", + "counts", + "admissible_candidate_ids", + "candidates", + "receipt" + ], + "type": "object" + } + }, + "required": [ + "result", + "handoff" + ], + "type": "object" +}
- Changed
preflight_hash_decision2 fields changed- changed
Input schema / properties / decision / descriptionPrevious value: -"Preflight v2 decision JSON document."New value: +"Preflight v2 object with schema_version \"2\", decision_id, context, and 1-100 unique candidate IDs with payloads." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": false, + "properties": { + "decision_hash": { + "description": "Canonical SHA-256 digest.", + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "decision_hash" + ], + "type": "object" +}
- Changed
preflight_hash_policy2 fields changed- changed
Input schema / properties / policy / descriptionPrevious value: -"Preflight v2 policy JSON document."New value: +"Owner-controlled Preflight v2 object with schema_version \"2\", policy_id, and 1-100 hard constraints using eq, in, lte, gte, or exists." - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": false, + "properties": { + "policy_hash": { + "description": "Canonical SHA-256 digest.", + "pattern": "^[a-f0-9]{64}$", + "type": "string" + } + }, + "required": [ + "policy_hash" + ], + "type": "object" +}
3 tool updates
- First observed
preflight_check - First observed
preflight_hash_decision - First observed
preflight_hash_policy
TDQS
Scored across 3 tools
The three tools target clearly distinct operations: evaluating candidate actions, hashing a decision, and hashing a policy. Although the two hash tools share the 'hash' verb, their inputs and purposes are unambiguous, and the descriptions explicitly separate them.
All tools use the same snake_case convention with a consistent 'preflight_' namespace prefix. The action suffixes are readable and predictable despite the slight grammatical difference between 'check' and 'hash_*'.
Three tools are well-scoped for a narrow preflight validation server. Each tool earns its place: one evaluation operation and two canonical hashing operations for the objects the server manages.
The surface covers the core lifecycle of checking candidates and pinning policies/decisions with canonical hashes. A minor gap is that there is no separate evidence/proposal hashing or inspection tool, but the stated workflow does not strictly require one.
Maintenance
Related MCP Connectors
Experimental AtlasClose governance demo. Authority checks, labeled evidence, receipts, refusals.
Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
Deterministic sealed verdicts on public claims and startup ideas (0-LLM claim-safety guardian).
Check claims against a fact-store: consistent, contradicts, or unverifiable — with a receipt.
Related MCP Servers
- AlicenseNot gradedqualityFmaintenanceEnables defining and verifying evidence contracts for claims in READMEs, releases, or product pages using constrained verifiers and generating hash-chained receipts and reports.3 npmMIT
- AlicenseNot gradedqualityBmaintenanceSelf-hosted MCP gateway that applies deterministic, compiled policy to tool discovery, invocation, and outbound data flow, with no model in the enforcement path. Every decision emits a hash-chained receipt sealed with Ed25519 and verifiable using public keys only.Apache 2.0
- AlicenseAqualityCmaintenanceEnables validating and verifying verifiable claims through structural checks, hash anchoring, and optional script execution, exposing self-test, validate, and verify tools over stdio.329 PyPIMIT
- AlicenseNot gradedqualityBmaintenanceEnables users to trace regulatory rule changes to affected parties and required actions through deterministic safety gates, returning dated action plans and hash-linked evidence records. Supports 12 MCP tools over stdio or streamable HTTP for source comparison, obligation decomposition, scope assessment, planning, and evidence validation across multiple domain packs.MIT