# ai.geodesiclabs/governance-platform > Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof. - name: ai.geodesiclabs/governance-platform - version: 1.2.0 - connection class: R0 (autonomous) - trust: 77/100 flags: no-repository - quality: 77/100 (good) - owner: not claimed - descriptor: https://api.protogrid.dev/v1/servers/ai.geodesiclabs%2Fgovernance-platform - tools: https://api.protogrid.dev/v1/servers/ai.geodesiclabs%2Fgovernance-platform/tools **An agent can connect right now, no human step.** Remote endpoint, no authentication, reachable on the last probe. ## Connection (mcpServers) ```json { "mcpServers": { "governance-platform": { "type": "http", "url": "https://app.geodesiclabs.ai/mcp" } } } ``` ## Trust - hygiene: 80 - liveness: 100 - freshness: 85 - provenance: 45 - drivers: +dns-namespace +reachable +uptime-100% ~updated-85d-ago -no-repository - Derived from observable signals (official registry feed and our own credential-free probes); no code audit performed. ## Quality 77/100 (good) ### protocol: 75 (weight 25) - warn `protocol.modern`: newest supported version is 2025-11-25; 2026-07-28 not supported, older versions are deprecated until 2027-07-28 - n/a `protocol.stateless`: only applies to 2026-07-28 servers - pass `protocol.transport`: streamable HTTP - n/a `protocol.list_ttl`: only applies to 2026-07-28 servers ### authorization: n/a (weight 15) - n/a `auth.prm`, `auth.as_metadata`, `auth.cimd`: no remote uses OAuth - n/a `auth.secret_in_url`: no templated URL ### tool hygiene: 93 (weight 30) - pass `tools.descriptions`: every tool has a description - pass `tools.description_length`: descriptions are concise - pass `tools.schemas`: every tool has an object input schema - pass `tools.annotations`: 37 of 37 tools declare readOnlyHint or destructiveHint - pass `tools.directory_hints`: every tool declares readOnlyHint, destructiveHint, idempotentHint and openWorldHint - warn `tools.token_cost`: about 9,805 tokens to load every tool - pass `tools.api_dump`: tools are not a one-to-one API dump ### stability: 50 (weight 15) - pass `stability.changes`: 2 tool changes in 30 days - fail `stability.rug_pull`: 1 tools kept their name but changed most of their description in 30 days; review before trusting them ### dependencies: n/a (weight 15) - n/a `deps.known_vulns`, `deps.mcp_sdk_version`, `deps.resolvable`: no npm or PyPI package - tools: 37, about 9,805 tokens to load them all - tool set hash: aca58c38c3b6983314caa6b859910b1c - tools last changed: 2026-10-13T23:09:36.747Z - badge: [![protogrid quality](https://protogrid.dev/badge/ai.geodesiclabs/governance-platform.svg)](https://protogrid.dev/servers/ai.geodesiclabs/governance-platform) - Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed. ### Tool changes - 2026-10-13 `decompose_failure` changed (description) **meaning changed** - before: Split the error between original and corrected values into direct rule violations, boundary violations, and systemic structural error, with per-field contributions. Use with a known-correct version to diff against; use analyze_anomaly when you only have the suspicious payload. Diagnostics-tier tool. - after: Measure the numeric difference between original and corrected values: how much lies along the supplied linear rule directions (projection) and how much lies outside them (residual), with per-field contributions. Diagnostic only: it does not establish a cause, and neither record is verified. Use with a known-correct version to diff against; use analyze_anomaly when you only have the suspicious payload. Diagnostics-tier tool. - 2026-10-13 `validate` changed (inputSchema) Full history: https://api.protogrid.dev/v1/servers/ai.geodesiclabs%2Fgovernance-platform/changes ## Remotes - https://app.geodesiclabs.ai/mcp (streamable-http, auth none, reachable true, uptime30d 1) ## Packages _none_ ## Tools (37) - `account_status`: This account's plan, key usage, Blueprint counts, and the deployed platform build fingerprint (version, build, deployed). - `analyze_anomaly`: Explain whether a record fits the usual pattern for records like it, and which fields stand out. No Blueprint required. - `approve_rule`: Promote a rule discovered by discover_patterns into Blueprint-ready form. - `authorize_execution`: Go/no-go for a real-world action (payment, filing, API write): runs full validation, then the Blueprint's execution gate. authorized=true only on PASS; REVIEW means do not proceed automatically. Different from validate: validate asks is this data correct, authorize_execution asks should this action happen. - `check_blueprint_health`: Static pre-deploy analysis of a Blueprint's rule set. Returns a health verdict - healthy, acceptable, fragile, rigid, split, brittle_islands, or unsatisfiable - with advice, including joint conflicts pairwise checks miss. - `check_drift`: Check whether recent submissions still match the established pattern for this Blueprint. Returns a stability verdict and observation count. - `check_realization`: Structural realization analysis of a payload against the Blueprint's reference configuration (requires a 'realization' block; otherwise status=skipped). Diagnostics-tier tool; prefer validate or analyze_anomaly for standard checks. - `compare_semantic_equivalence`: Compare two payloads under the dual-hash design: content_hash is content_hash normalizes field order and numeric formatting. Semantic comparison preserves field roles; renaming requires an explicit bijection. With supplied rules, scalar types and whitespace remain significant. Structural similarity alone does not establish decision equivalence. - `counterfactual`: Run the same data under two rule sets and compare which future states remain valid - what-if analysis for rule changes. - `create_blueprint`: Create a Blueprint - the governance contract validation runs against. A Blueprint defines what correct means for your data: fields, the math that must hold between them, and acceptable ranges. Start from load_rule_pack or discover_patterns if you have no rules yet; invoke the blueprint_guide prompt for the full rule/constraint reference. Returns the new Blueprint's API key. - `create_chain`: Create a multi-agent sequential chain: stages validate in order against one Blueprint, repairs propagate forward, TTL bounds the run. Siblings: submit_chain_stage advances the chain; handoff_audit verifies a transition between stages. Returns chain_id. - `decompose_failure`: Measure the numeric difference between original and corrected values: how much lies along the supplied linear rule directions (projection) and how much lies outside them (residual), with per-field contributions. Diagnostic only: it does not establish a cause, and neither record is verified. Use with a known-correct version to diff against; use analyze_anomaly when you only have the suspicious payload. Diagnostics-tier tool. - `delete_api_key`: Permanently delete one of the caller's API keys. DESTRUCTIVE — agents using the deleted key will receive auth errors immediately. The Blueprint a key was tied to (if any) is NOT affected; only the credential is revoked. To delete a Blueprint and all its keys, use delete_blueprint. The target key can be specified two ways: - As the full key string (gai_...). - As a key_id (SHA-256 hash from list_api_keys). - `delete_blueprint`: Permanently delete a Blueprint and revoke its API keys. Irreversible; requires confirm=true. Account-level keys are unaffected. - `discover_patterns`: Learn candidate validation rules and structural document types from a batch of your records, deterministically - no Blueprint required. Promote results with approve_rule. Source data is not stored. - `forecast`: Deterministic forward reasoning: from the current data state, generate and rank the valid next states reachable under the Blueprint's rules. - `geometric_confidence`: Summarize an already-computed state_vector into a confidence level (high/medium/low) with a recommendation. Post-hoc digest - use analyze_anomaly or check_drift for fresh analysis of raw data. - `get_execution_trace`: Run validation and return the per-node execution trace (node names, deterministic flags, timing) plus the verdict and determinism hash. Use validate for normal operation; this is for debugging and audit preparation. - `get_inference_trace`: Retrieve the durable audit trail for a governed generation: every recorded decision and its reasons. - `govern_inference`: Quality-govern an in-progress AI generation step BEFORE its output is used (complements validate, which checks finished documents). Returns an action - STOP, CONTINUE, REPAIR_REGION, REUSE_MOTIF, REVIEW, ESCALATE - with a plain-language explanation. Structural scores do not establish task correctness. Check safe_to_finalize and acceptance coverage. Persistence success is reported; read traces in the same Blueprint namespace. - `handoff_audit`: Audit a handoff between two chain stages: a context capsule of verified facts from the prior stage, and (if proposed_data is given) a compatibility verdict that catches fields mutated in transit. Siblings: create_chain, submit_chain_stage. - `list_api_keys`: List this account's API keys (masked) with their Blueprint bindings. - `list_blueprints`: List the Blueprints on this account with field/rule/constraint counts and mode. Use the returned workflow_name as 'blueprint' in validate. - `load_rule_pack`: Load a prebuilt Blueprint template (invoices, timecards, legal, POs, claims). Call without pack_id to list packs; then create_blueprint to save a customized copy. - `profile_blueprint_robustness`: Sweep the Blueprint's numeric constraint bounds and report verdict stability: the stable band, the scales where the verdict first flips, and advice. Use before deploying bound changes. - `recent_inference_decisions`: Recent generation-governance decisions in this owner's Blueprint version. - `reject_rule`: Reject a discovered candidate rule so it will not be promoted into a Blueprint. Pair with approve_rule after discover_patterns. - `repair`: One-shot repair: return corrected values that would make failing data valid under the Blueprint. Use repair_path to see the steps instead. - `repair_path`: Find the shortest sequence of field changes taking invalid data to a valid state, as an ordered path of intermediate states. Different from repair (one-shot nearest fix): use repair_path to explain or audit the fix, or compare alternative repairs. - `rotate_api_key`: Replace an API key with a fresh one. The old key stops working immediately; the new key inherits its bindings. - `structural_types`: Retrieve the document categories a discover_patterns session identified (counts, distinguishing fields, domain hints). Read-only; returns status=no_session if discovery has not run for this namespace. - `submit_chain_stage`: Submit data for the chain's current stage; the platform validates it and advances the chain if it passes. Response includes next-stage info and accumulated repairs. - `update_blueprint`: Update an existing Blueprint in place. Only passed fields change; pass [] to clear a list. workflow_name cannot be renamed and existing API keys keep working. Different from create_blueprint: modifies an existing Blueprint, mints no new key. - `validate`: Validate structured data against a Blueprint's rules BEFORE the result is used. Returns PASS, FAIL, or REVIEW with plain-language findings, repair suggestions, a determinism hash, and a re-verifiable certificate. Same input + same rules = same verdict, every time. - `validate_repair`: Validate structured data against a Blueprint and, when it fails, include repair suggestions (corrected values with the rule each fix is based on) in the same call. Same verdicts as validate: PASS, FAIL, or REVIEW, with reasons and proof. - `verify_certificate`: Independently re-verify a validation certificate. Integrity mode checks the hash chain; full mode (certificate + original data) recomputes every attested rule from scratch - trust nothing, recheck everything. - `verify_replay`: Check replay commitment integrity and compare recorded execution components. Version 4 includes reference context and the final result/status. A match compares commitments; this tool does not rerun the workflow or reconstruct historical reference populations, and does not prove factual correctness.