Omega Brain MCP is the governing cognitive substrate of the VERITAS & Sovereign Ecosystem (Omega Universe). Where other memory layers persist context, Omega Brain enforces it: every execution path passes through the Cortex approval gate, every state transition is sealed to a tamper-proof SHA-3-256 audit ledger, and every artifact claim must survive a 10-gate deterministic build pipeline before a verdict is issued. It does not make trust decisions on behalf of the operator — it enforces the constraints the operator has declared, cryptographically and without exception. In the Omega Universe, Omega Brain MCP is the control plane: the point where agent autonomy ends and declared policy begins.
SYSTEM INVARIANT: VERITAS Build does not determine whether code is 'good.' VERITAS Build determines whether code survives disciplined attempts to break it under explicitly declared primitives, constraints, test regimes, boundaries, cost models, evidence, and policy.
Related MCP server: PiQrypt MCP Server
Omega Brain MCP is a self-contained Model Context Protocol (MCP) server that runs as a local process alongside any MCP-compatible AI client. It exposes 26 tools and 9 resources covering four governance domains:
Cross-session episodic memory — SQLite vault with full-text search, persisted across all restarts
10-gate VERITAS build pipeline — deterministic artifact evaluation from INTAKE through TRACE/SEAL
Cryptographic S.E.A.L. audit ledger — append-only SHA-3-256 hash chain; every operation is sealed
Cortex approval gate — Tri-Node similarity gate that enforces declared baseline policy on every tool call
Two Python files. One pip dependency. Zero external services.
Compatible clients: Claude Desktop, VS Code Copilot, Cursor, Windsurf, AutoGen, LangChain, CrewAI, LlamaIndex, and any MCP-compliant host.
Not a cloud service. No network egress, no API keys, no telemetry. All data remains on the operator's machine under ~/.omega-brain/ (or OMEGA_BRAIN_DATA_DIR).
Not a language model. Omega Brain does not generate text. It governs, routes, stores, and audits agent operations.
Not a policy authority. VERITAS gates enforce what the operator declares. The system cannot determine correctness beyond what its evidence and constraints describe.
Not a firewall or OS-level isolation layer. See the Threat Model for explicit out-of-scope boundaries.
Vault (SQLite + FTS5) — sessions, entries, and events persist across restarts; auto-loaded at startup via omega://session/preload
Semantic RAG provenance — 3-tier embedding engine: sentence-transformers → fastembed ONNX → TF-IDF n-gram; always available with no GPU requirement
Sealed handoff — SHA-256 signed cross-session memory file; auto-loaded on restart, auto-written on task seal
Full deterministic evaluation pipeline: INTAKE → TYPE → DEPENDENCY → EVIDENCE → MATH → COST → INCENTIVE → SECURITY → ADVERSARY → TRACE/SEAL
Every gate returns a structured verdict (PASS, MODEL_BOUND, INCONCLUSIVE, or VIOLATION). The pipeline seals the final result as a cryptographically identified record. Fail-fast on VIOLATION by default.
Append-only SHA-3-256 hash chain
Every Cortex check, ingest, session log, gate run, and execution is automatically sealed
Chain integrity is verifiable at any point; any tampered entry breaks the chain
Persisted to omega_ledger.json under the data directory
Tri-Node similarity gate evaluates every tool call against the operator-declared baseline prompt
Hard-block window < 0.45 — execution is refused; event sealed to ledger
Steer window 0.45–0.65 — arguments are corrected toward baseline alignment before execution
Blocks NAFE drift (narrative rescue, moral override, authority drift, intent inference) before execution
CLAEG state machine governs terminal states: STABLE_CONTINUATION, ISOLATED_CONTAINMENT, TERMINAL_SHUTDOWN; absence of allowed transition is prohibition
Two transports — stdio (default, MCP standard) and SSE (HTTP streaming for web clients)
Docker-ready — single Dockerfile, non-root user, unbuffered I/O
Single dependency — mcp>=1.0.0; optional fastembed or sentence-transformers for higher-quality embeddings
Fully local — no cloud, no API keys, no external server required
┌─────────────────────────────────────────────────────────────────┐
│ MCP CLIENT │
│ (Claude Desktop / VS Code Copilot / Cursor / AutoGen / ...) │
└───────────────────────────┬─────────────────────────────────────┘
│ MCP stdio / SSE (JSON-RPC 2.0)
▼
┌─────────────────────────────────────────────────────────────────┐
│ OMEGA BRAIN MCP SERVER │
│ omega_brain_mcp_standalone.py │
│ │
│ ┌──────────────────────────┐ ┌──────────────────────────────┐ │
│ │ BRAIN CORE │ │ VERITAS BUILD GATES │ │
│ │ │ │ │ │
│ │ Cortex Approval Gate │ │ 10-Gate Pipeline │ │
│ │ (Tri-Node, steer/block) │ │ INTAKE → TYPE → DEPENDENCY │ │
│ │ │ │ → EVIDENCE → MATH → COST │ │
│ │ RAG Provenance Store │ │ → INCENTIVE → SECURITY │ │
│ │ (3-tier embeddings) │ │ → ADVERSARY → TRACE/SEAL │ │
│ │ │ │ │ │
│ │ S.E.A.L. Audit Ledger │ │ Evidence Engine │ │
│ │ (SHA-3-256 hash chain) │ │ (Quality(e), MIS_GREEDY) │ │
│ │ │ │ │ │
│ │ Sealed Handoff │ │ CLAEG State Machine │ │
│ │ (SHA-256 cross-session) │ │ NAFE Scanner │ │
│ └──────────┬───────────────┘ └────────────────┬─────────────┘ │
└─────────────│──────────────────────────────────│───────────────┘
│ │
▼ SQLite ▼ Pure Python
┌─────────────────────┐ ┌─────────────────────────┐
│ ~/.omega-brain/ │ │ veritas_build_gates.py │
│ omega_vault.db │ │ (stateless, no I/O, │
│ omega_ledger.json │ │ reproducible verdicts)│
│ omega_handoff.json│ └─────────────────────────┘
└─────────────────────┘Layer | Component | Role |
Brain Core | Vault (SQLite) | Persistent session/entry storage with FTS5 full-text search |
Brain Core | S.E.A.L. Ledger | Append-only SHA-3-256 hash chain for tamper-proof audit |
Brain Core | RAG Provenance | Semantic embedding store — 3-tier engine (ST / fastembed / TF-IDF) |
Brain Core | Cortex | Tri-Node approval gate with steer/block modes |
Brain Core | Handoff | SHA-256 sealed cross-session memory transfer |
Build Gates | 10-Gate Pipeline | INTAKE→TYPE→DEPENDENCY→EVIDENCE→MATH→COST→INCENTIVE→SECURITY→ADVERSARY→TRACE/SEAL |
Build Gates | Evidence Engine | Quality(e) formula, MIS_GREEDY independence scoring, Agreement computation |
Build Gates | CLAEG | Constraint-locked state machine with 3 terminal states |
Build Gates | NAFE Scanner | Narrative failure signature detection and auto-seal |
🏛️ Protocol Standard: The
omega-brain-mcpis the official execution engine for the VERITAS Ω-CODE v2.0 specification. The structural gates here enforce the deterministic claims that power veritas-vault session capture, AEGIS remediation, and Sovereign artifacts.
Verdict | Precedence | Meaning |
| 0 (lowest) | All gates satisfied. Artifact is deployable under declared regime. |
| 1 | Gates pass but resource/coverage/confidence near redline. Deploy with monitoring. |
| 2 | Insufficient evidence or timeout. Cannot affirm or deny. Block deploy. |
| 3 (highest) | Constraint failure, security vulnerability, or test failure. Block deploy. |
Requirement | Details |
Python | 3.11 or 3.12 |
Core dependency |
|
OS | Linux, macOS, Windows (WSL2 recommended on Windows) |
Disk | ~5 MB for source + SQLite data dir (default |
Optional |
|
Optional |
|
Embedding engine auto-selection: The server probes for
sentence-transformersfirst, thenfastembed, then falls back to built-in TF-IDF n-gram. You always get semantic search — richer models improve recall quality.
pip install omega-brain-mcpgit clone https://github.com/VrtxOmega/omega-brain-mcp.git
cd omega-brain-mcp
pip install mcp
# Optional: better embeddings
pip install fastembed # recommended — fast ONNX, no GPU
pip install sentence-transformers numpy # best quality, larger downloaddocker build -t omega-brain-mcp .
docker run --rm -i omega-brain-mcp # stdio mode (MCP standard)
docker run --rm -p 8055:8055 omega-brain-mcp --sse --port 8055 # SSE modepip install pytest pytest-asyncio pytest-cov
PYTHONUTF8=1 OMEGA_BRAIN_DATA_DIR=/tmp/omega-test pytest tests/ -v --tb=shortpython omega_brain_mcp_standalone.py --helpThe server reads JSON-RPC 2.0 messages from stdin and writes responses to stdout. MCP clients manage this process automatically via the config below.
python omega_brain_mcp_standalone.pypython omega_brain_mcp_standalone.py --sse --port 8055
# GET http://localhost:8055/sse — event stream
# POST http://localhost:8055/messages — send tool callsecho '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"omega_brain_status","arguments":{}}}' \
| python omega_brain_mcp_standalone.pyEdit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"omega-brain": {
"command": "python",
"args": ["/absolute/path/to/omega_brain_mcp_standalone.py"],
"env": { "PYTHONUTF8": "1" }
}
}
}Add to .vscode/mcp.json in your workspace (or user settings):
{
"servers": {
"omega-brain": {
"type": "stdio",
"command": "python",
"args": ["/absolute/path/to/omega_brain_mcp_standalone.py"],
"env": { "PYTHONUTF8": "1" }
}
}
}In Cursor Settings → MCP → Add Server:
{
"mcpServers": {
"omega-brain": {
"command": "python",
"args": ["/absolute/path/to/omega_brain_mcp_standalone.py"],
"env": { "PYTHONUTF8": "1" }
}
}
}In ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"omega-brain": {
"command": "python",
"args": ["/absolute/path/to/omega_brain_mcp_standalone.py"],
"env": { "PYTHONUTF8": "1" }
}
}
}{
"mcpServers": {
"omega-brain": {
"type": "sse",
"url": "http://localhost:8055/sse"
}
}
}Variable | Default | Description |
|
| Set to |
|
| Override the data directory for vault, ledger, and handoff files |
Omega Brain MCP integrates with any MCP-compatible client using standard JSON-RPC 2.0 over stdio or SSE. For framework-specific integration patterns (LangChain, CrewAI, AutoGen, LlamaIndex) see INTEGRATIONS.md and the examples/ directory.
For production use, keep one persistent server process across all calls. This avoids the 2–3s cold-start cost of loading the embedding model and SQLite on every call.
from omega_client import OmegaBrainClient
client = OmegaBrainClient() # starts server subprocess once
# Governance-first: always run a Cortex check before executing
check = client.call("omega_cortex_check", {
"tool": "omega_rag_query",
"args": {"query": "sensitive project data"},
"baseline_prompt": "You are a data analysis agent. Only access approved datasets."
})
# {"approved": true, "similarity": 0.71, "verdict": "APPROVED", "node_votes": [1, 1, 1]}
# Memory retrieval
result = client.call("omega_rag_query", {"query": "VERITAS evidence thresholds", "top_k": 5})
# Run VERITAS build gate pipeline
verdict = client.call("veritas_run_pipeline", {"claim": {...}, "regime": "baseline"})
# Session persistence — always seal before terminating
client.call("omega_seal_task", {})
client.close()Goal | Tool | Notes |
Pre-action guard (binary) |
| Returns |
Pre-action guard + auto-fix |
| Returns steered args if in 0.45–0.65 window |
Full Cortex-wrapped execution |
| Omega Brain tools only; returns steered_args for external tools |
Memory / context retrieval |
| Use at agent task start |
Human-readable audit |
| SEAL chain tail, blocked count, VERITAS avg |
Session persistence |
| One call, no fields required |
Full artifact evaluation |
| 10-gate deterministic verdict + seal hash |
All examples use JSON-RPC 2.0. In practice, your MCP client sends these automatically when you invoke a tool. The shell one-liner form is useful for testing.
echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"omega_brain_status","arguments":{}}}' \
| python omega_brain_mcp_standalone.pyResponse (abbreviated):
{
"result": {
"content": [{
"type": "text",
"text": "{\"vault_sessions\": 3, \"vault_entries\": 42, \"rag_fragments\": 18, \"ledger_entries\": 127, \"embedding_engine\": \"fastembed\", \"omega_status\": \"OK\"}"
}]
}
}{
"jsonrpc": "2.0", "id": 4,
"method": "tools/call",
"params": {
"name": "omega_cortex_check",
"arguments": {
"tool": "omega_rag_query",
"args": {"query": "sensitive user data"},
"baseline_prompt": "You are a data analysis agent. Only access approved datasets."
}
}
}Response:
{"approved": true, "similarity": 0.71, "verdict": "APPROVED", "node_votes": [1, 1, 1]}{
"jsonrpc": "2.0", "id": 5,
"method": "tools/call",
"params": {
"name": "veritas_run_pipeline",
"arguments": {
"claim": {
"claim_id": "claim-001",
"artifact_type": "function",
"description": "Validates user authentication tokens",
"primitives": ["jwt", "hmac-sha256"],
"evidence": [
{
"id": "e1", "type": "test_suite",
"provenance": 0.9, "repeatability": 0.95,
"freshness": 0.85, "env_match": 1.0
}
],
"constraints": [{"op": "lte", "left": "latency_ms", "right": 50}],
"cost": {"cpu_p95": 0.3, "memory_gb_p95": 0.1},
"security": {"sast_findings": [], "secrets_found": false}
},
"regime": "baseline"
}
}
}Response:
{
"verdict": "PASS",
"gates_passed": 10,
"seal_hash": "a3f9c2...",
"pipeline_ms": 12,
"omega_status": "OK"
}{
"jsonrpc": "2.0", "id": 6,
"method": "tools/call",
"params": {
"name": "veritas_nafe_scan",
"arguments": {
"text": "Although the tests failed, the developer clearly intended the function to work correctly, so we can assume it passes."
}
}
}Response:
{
"nafe_detected": true,
"signatures": ["NARRATIVE_RESCUE", "INTENT_INFERENCE"],
"seal_hash": "b7d1e4...",
"omega_status": "NAFE_VIOLATION"
}Tool | Purpose |
| Episodic task briefing: RAG + vault + sealed handoff + VERITAS score |
| Semantic search over RAG provenance store |
| Add text fragment to RAG store |
| Full-text keyword search across vault entries |
| Tri-Node approval gate with similarity scoring |
| Cortex correction mode — steer drifting args or hard block |
| Append tamper-proof S.E.A.L. entry to audit ledger |
| Write session record to vault |
| SHA-256 sealed cross-session handoff |
| Cortex-wrapped meta-tool — default execution path |
| Human-readable audit report |
| Unified brain health: vault stats, fragment count, ledger entries |
Tool | Purpose |
| Gate 1/10: Canonicalize, validate fields, compute ClaimID |
| Gate 2/10: Primitives, domains, operators, symbols |
| Gate 3/10: SBOM, CVE, integrity, licenses, depth |
| Gate 4/10: MIS_GREEDY, Quality(e), K/A/Q thresholds |
| Gate 5/10: Constraint satisfaction via interval arithmetic |
| Gate 6/10: Resource utilization vs redline thresholds |
| Gate 7/10: Source dominance and vendor concentration |
| Gate 8/10: SAST, secrets, injection, auth, crypto |
| Gate 9/10: Fuzz, mutation, exploit, outage, spike |
| Full 10-gate pipeline — final verdict + seal hash |
| Compute Quality(e) for single evidence item |
| Run MIS_GREEDY algorithm on evidence items |
| Map verdict to CLAEG terminal state |
| Validate state transition (absence = prohibition) |
| Scan for NAFE failure signatures in AI text |
URI | Description |
| Auto-fetched at startup: RAG + handoff + vault context |
| SHA-256 verified cross-session handoff |
| Session ID, call count, data directory |
| DB stats, embedding engine, ledger count |
| Full canonical VERITAS Omega Build Spec v2.0.0 |
| Terminal states, transitions, invariants, prohibitions |
| The 10-gate pipeline sequence |
| Dev/baseline regime numeric thresholds |
| Escalated production regime thresholds |
INIT → { STABLE_CONTINUATION | ISOLATED_CONTAINMENT | TERMINAL_SHUTDOWN }
STABLE_CONTINUATION → { STABLE_CONTINUATION | ISOLATED_CONTAINMENT | TERMINAL_SHUTDOWN }
ISOLATED_CONTAINMENT → { STABLE_CONTINUATION | TERMINAL_SHUTDOWN }
TERMINAL_SHUTDOWN → {} (absorbing)Invariant: Absence of an allowed transition is treated as prohibition. TERMINAL_SHUTDOWN is absorbing — there are no exit transitions.
State | Meaning |
| Normal operation; execution proceeds |
| Anomaly detected; execution continues under isolation |
| Critical failure; execution halted, no recovery |
omega-brain-mcp/
├── omega_brain_mcp_standalone.py # MCP server — Brain Core + tool dispatch (~1430 lines)
├── veritas_build_gates.py # Gate engine — pure deterministic logic (~1430 lines)
├── omega_client.py # Python client helper (persistent process)
├── requirements.txt # mcp>=1.0.0
├── pyproject.toml # Package config + optional deps
├── Dockerfile # Non-root, unbuffered, stdio + SSE
├── INTEGRATIONS.md # LangChain, CrewAI, AutoGen, LlamaIndex guides
├── SECURITY.md # Vulnerability reporting policy
├── CHANGELOG.md # Release history
├── docs/
│ └── integration.md # Detailed integration reference
├── examples/
│ ├── langchain_quickstart.py
│ ├── crewai_quickstart.py
│ ├── autogen_quickstart.py
│ └── llamaindex_quickstart.py
└── tests/
├── test_build_gates.py # Gate pipeline tests
├── test_veritas.py # VERITAS scoring tests
├── test_seal.py # SEAL chain integrity tests
├── test_handoff.py # Handoff seal/context tests
├── test_cortex.py # Cortex approval tests
└── test_vault.py # Vault persistence testsModuleNotFoundError: mcppip install mcpUnicodeDecodeError on WindowsSet the environment variable before running:
set PYTHONUTF8=1
python omega_brain_mcp_standalone.pyOr add "env": { "PYTHONUTF8": "1" } to your MCP client config.
Confirm the path in your client config is absolute (e.g., C:\Users\you\omega-brain-mcp\omega_brain_mcp_standalone.py), not relative.
Run the server manually in a terminal to see startup errors: python /path/to/omega_brain_mcp_standalone.py
Check Python version: python --version must be 3.11+.
Install a better embedding backend:
pip install fastembed # fast, no GPU, ~30MB download — recommended
# or
pip install sentence-transformers numpy # highest qualityThe server auto-selects the best available engine at startup and logs which tier is active.
NAFE_VIOLATION returned unexpectedlyThe NAFE scanner detected a narrative failure pattern (rescue framing, intent inference, moral override, or authority drift) in the text passed to veritas_nafe_scan. Review the signatures field in the response for the specific pattern detected, then revise the input text to state facts without narrative interpretation.
Delete the data directory and restart to rebuild from scratch (all persisted memory will be lost):
rm -rf ~/.omega-brain/
python omega_brain_mcp_standalone.pyTo use a separate data directory per project:
OMEGA_BRAIN_DATA_DIR=/path/to/project-brain python omega_brain_mcp_standalone.pyConnection refused on port 8055Ensure the server is running with --sse --port 8055 and that the port is not blocked by a firewall. Check with:
curl -N http://localhost:8055/sseAll data is local. The vault, S.E.A.L. ledger, RAG store, and handoff file are stored in ~/.omega-brain/ (or OMEGA_BRAIN_DATA_DIR). No data is transmitted to any external service.
No API keys required. The server requires only a local Python installation and the mcp package.
Cryptographic integrity. The S.E.A.L. ledger uses SHA-3-256 hash chaining; any tampering with a past entry breaks the chain. Handoff files are SHA-256 sealed.
Cortex blocks drift. The Cortex gate hard-blocks tool calls with similarity below 0.45 to the declared baseline prompt, preventing prompt injection from steering the agent off its declared mission.
NAFE guardrails. The NAFE scanner detects and seals AI narrative failures — including attempts to override constraints via ethical framing or authority assertions — before they propagate.
Non-root Docker. The provided Dockerfile runs as a non-root omega user.
VERITAS gates are stateless and deterministic. veritas_build_gates.py has no network calls, no file I/O, and no side effects. All verdicts are reproducible given the same input.
Sensitive data handling. Do not ingest secrets, credentials, or PII into the RAG store or vault. The vault is unencrypted SQLite on disk; protect it with OS-level file permissions.
For vulnerability reporting, see SECURITY.md.
Threat | Mitigation |
Tampered audit records | S.E.A.L. SHA-3-256 hash chain; any modified entry breaks chain verification |
Agent prompt injection steering execution off declared baseline | Cortex Tri-Node gate hard-blocks calls below similarity threshold |
AI narrative failures bypassing constraints | NAFE scanner detects and seals rescue framing, moral override, intent inference, authority drift |
Unapproved state transitions in agent execution | CLAEG state machine; absence of allowed transition is prohibition |
Artifact deployment without declared evidence | VERITAS 10-gate pipeline requires structured evidence, constraints, and cost model before issuing a verdict |
Unsigned or tampered cross-session memory | Handoff files are SHA-256 sealed; tampering is detected on load |
The following threats are not addressed by Omega Brain MCP:
Compromised host or operating system — if the process environment is controlled by an adversary, no application-layer protection is sufficient
Stolen or leaked vault encryption keys — the vault is unencrypted SQLite; OS-level access controls are the operator's responsibility
Malicious administrator — an operator with filesystem access can modify or delete the data directory directly
Supply-chain compromise of mcp or Python itself — dependency integrity verification is the operator's responsibility; use lock files and hash verification
Network-level attacks — SSE mode exposes an HTTP endpoint; TLS termination and network access control are the operator's responsibility
Model-level jailbreaks — Cortex gates on declared tool calls; it does not govern the language model's internal reasoning or responses
[ MCP Client / AI Agent ]
│
│ Trust: MCP client is the operator's declared agent.
│ Baseline prompt defines the trust contract.
▼
[ Omega Brain MCP Server ] ← Enforcement boundary
│
│ Trust: Local filesystem is operator-controlled.
│ No external services are contacted.
▼
[ ~/.omega-brain/ (vault, ledger, handoff) ]The Cortex gate is the primary trust enforcement point. All tool calls cross this boundary. The VERITAS pipeline enforces evidence-based policy on artifact claims. The S.E.A.L. ledger provides a tamper-evident record of all crossings.
Milestone | Status | Description |
v2.1 — Core governance stack | Released | Cortex gate, S.E.A.L. ledger, 10-gate VERITAS pipeline, CLAEG, NAFE |
v2.2 — Vault encryption | Planned | Optional AES-256-GCM encryption for the local SQLite vault |
v2.3 — Ledger export & attestation | Planned | Structured ledger export for external audit tools; Merkle root attestation |
v2.4 — Multi-agent handoff | Planned | Verified cross-agent memory transfer with provenance chain |
v3.0 — Ecosystem bridge | Planned | Native integration with Aegis policy engine and Veritas Vault retention layer |
Community contributions are welcome. See CONTRIBUTING.md for invariants that must not be broken.
Omega Brain MCP is the governance control plane of the VERITAS & Sovereign Ecosystem. The following repositories form the broader Omega Universe:
Repository | Role |
This repo — Governance control plane: Cortex gate, VERITAS pipeline, S.E.A.L. ledger | |
Retention substrate — deterministic storage under VERITAS constraints | |
Policy enforcement engine — sovereign access control layer | |
Next-generation Aegis rewrite | |
Semantic drift detection and correction for agent pipelines | |
Sovereign desktop media application | |
Local LLM bridge — Ollama integration with Omega governance layer | |
Sovereign application arcade |
📖 Read the master narrative: Why Sovereign AI?
This project is part of the VERITAS Omega Universe — a sovereign AI infrastructure stack.
VERITAS-Omega-CODE — Deterministic verification spec (10-gate pipeline)
Gravity-Omega — Desktop AI operator platform
Ollama-Omega — Ollama MCP bridge for any IDE
OmegaWallet — Desktop Ethereum wallet (renderer-cannot-sign)
veritas-vault — Local-first AI knowledge engine
sovereign-arcade — 8-game arcade with VERITAS design system
SSWP — Deterministic build attestation protocol
MIT — see LICENSE for full text.
Generates a human-readable audit report showing SEAL chain entries, Cortex verdicts, and vault statistics. Use this to inspect the trust and governance layer; use omega_brain_status for a quick health summary instead. Returns formatted text report with sections: seal_tail, cortex_verdicts, vault_stats, session_health.
| Name | Required | Description | Default |
|---|---|---|---|
| lines | No | Number of recent SEAL ledger entries to include, between 1 and 100. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the output as a formatted text report with sections, implying it is a read-only operation. It does not disclose any potential side effects or required permissions, but the behavior is reasonably transparent for an audit report generator.
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?
The description is a compact two sentences: first states purpose and contents, second gives usage guidance and output structure. No superfluous words, every sentence valuable.
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?
Given the tool has one simple parameter, no output schema, and no annotations, the description covers the necessary context: what it does, when to use it, and what the output contains. It is complete for an AI agent to select and invoke correctly.
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?
The input schema has one parameter with description already covering range and default. The description does not add additional semantic information about the parameter beyond what the schema provides. With 100% schema description coverage, baseline score of 3 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?
The description clearly states the tool generates a human-readable audit report with specific contents (SEAL chain entries, Cortex verdicts, vault statistics). The verb 'generates' and resource 'audit report' are specific. It also distinguishes from the sibling 'omega_brain_status' by mentioning it's for a quick health summary instead.
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?
Explicitly says 'Use this to inspect the trust and governance layer; use omega_brain_status for a quick health summary instead.' This provides clear when to use and when not, with an alternative sibling tool named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a quick health summary of all Omega Brain subsystems as structured JSON. Use this for a fast status check; use omega_brain_report for a detailed audit report instead. Returns JSON with fields: vault_sessions (int), vault_entries (int), rag_fragments (int), seal_entries (int), session_id (string), uptime_seconds (float), call_count (int).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It lists the return fields (vault_sessions, vault_entries, etc.) but does not explicitly state that the operation is non-destructive or read-only. However, 'health summary' strongly implies no side effects, and the return structure is transparent.
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?
The description is two sentences: the first states the purpose concisely, and the second provides usage alternatives and lists return fields. Every sentence is informative and no extraneous detail.
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?
Given zero parameters and no output schema, the description sufficiently covers return values by listing all fields with types. It is complete for a simple status check tool.
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?
The input schema has no parameters, and schema description coverage is 100% (vacuously). The description adds no parameter information because there are none. Per guidelines, with high coverage and no params, baseline is 3.
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?
The description clearly states that the tool returns a quick health summary of Omega Brain subsystems as structured JSON. It uses specific verbs and resources ('returns', 'health summary of all Omega Brain subsystems') and distinguishes itself from the sibling tool omega_brain_report.
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?
The description explicitly provides usage guidance: use this for a fast status check, and use omega_brain_report for a detailed audit report instead. This clearly delineates when to use this tool versus an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only alignment gate that measures semantic similarity between a proposed action and the task baseline. Use this to check alignment before high-impact operations without modifying any arguments; use omega_cortex_steer instead if you want automatic argument correction. Returns JSON with fields: approved (boolean), similarity (float 0-1), verdict (APPROVED | BLOCKED).
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes | Name of the tool to check alignment for, e.g. 'omega_ingest'. | |
| args | Yes | The proposed arguments for the tool call, serialized as a JSON object. | |
| baseline_prompt | Yes | Task baseline describing the intended operation, e.g. 'Refactoring the auth module for OAuth2 support'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clearly states the tool is read-only, does not modify arguments, and returns JSON with fields approved, similarity, and verdict. The description discloses the boolean and float range (0-1) and verdict values. However, it omits any mention of potential error handling, rate limits, or authentication requirements.
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?
The description is two sentences with no filler. Every sentence adds value: first defines the tool, second gives usage guidance and return format. Front-loaded with key information.
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?
Given the tool has 3 parameters, no output schema, and no annotations, the description provides sufficient context: purpose, usage, return format, read-only nature. It lacks details on error conditions or edge cases, but for a read-only alignment check, this is largely adequate.
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%, so the schema already documents all parameters. The description adds marginal value by implying the purpose of baseline_prompt as 'task baseline describing the intended operation', but the schema already provides similar detail. Baseline 3 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?
The description explicitly states the tool is a 'read-only alignment gate' that measures semantic similarity between a proposed action and task baseline. It clearly distinguishes from sibling omega_cortex_steer by specifying that this tool does not modify arguments. The verb 'check' and resource 'alignment' provide specific purpose.
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?
The description gives explicit usage context: 'Use this to check alignment before high-impact operations' and names the alternative omega_cortex_steer for automatic argument correction. This makes it clear when to use this tool vs. its sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Alignment gate with automatic argument correction for drifting tool calls. Use this instead of omega_cortex_check when you want arguments auto-corrected toward the baseline; blocks hard if similarity < 0.45, steers if 0.45-0.65, passes unchanged if > 0.65. Returns JSON with fields: similarity (float), steered_args (object), corrections (array), verdict (PASSED | STEERED | BLOCKED).
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes | Name of the tool whose arguments may need correction, e.g. 'omega_seal_run'. | |
| args | Yes | The original arguments that may be drifting from baseline. Will be corrected if in the steering range. | |
| baseline_prompt | Yes | Task baseline to steer toward, e.g. 'Deploying hotfix to staging environment'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description carries burden well. It discloses the core behavior (block, steer, pass) based on similarity, and specifies the JSON return structure with fields. However, it does not explicitly mention side effects (e.g., logging, persistence) or whether the tool modifies state beyond returning a result.
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?
Description is single paragraph, front-loading purpose and sibling distinction, then thresholds, then return format. Every sentence adds value; no wasted words.
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?
Given no output schema, description fully specifies the return format (JSON with similarity, steered_args, corrections, verdict). It covers inputs, behavior thresholds, and differentiates from sibling. All necessary context for an AI agent to use this gate tool correctly is present.
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?
Input schema has 100% description coverage – each parameter is already clearly explained. The description adds no further detail about individual parameters beyond what schema provides, but it contextualizes them within the tool's behavior. Baseline score of 3 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?
Description clearly states it's an alignment gate with automatic argument correction, and explicitly distinguishes from sibling omega_cortex_check by specifying when to use this tool ('Use this instead of omega_cortex_check when you want arguments auto-corrected'). The verb 'steer' and resource 'tool arguments' are specific.
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?
Provides explicit thresholds for when to use: similarity < 0.45 blocks, 0.45-0.65 steers, > 0.65 passes unchanged. Also names the alternative (omega_cortex_check) and the preferred use case (when auto-correction desired).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cortex-governed execution wrapper that checks alignment, steers if needed, executes, and auto-logs to the SEAL chain. Use this as the default way to invoke any Omega Brain tool with full governance; only wraps Omega Brain tools — external tools are returned with steered_args for manual invocation. Returns JSON with fields: result (object), cortex_verdict (string), seal_hash (hex string).
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes | Omega Brain tool name to execute, e.g. 'omega_ingest', 'omega_rag_query', 'omega_seal_run'. | |
| args | Yes | Arguments for the target tool. May be steered by the Cortex before execution. | |
| baseline | Yes | Task baseline for the Cortex alignment check, e.g. 'Ingesting code review findings'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses the governance process: alignment check, possible steering, execution, and auto-logging. It also mentions that external tools return steered_args instead of executing. However, it does not describe what happens if alignment fails or provide details on potential side effects (e.g., cost, state changes). Overall, fairly transparent.
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?
Two sentences: first sentence packs core purpose and behavior; second sentence provides usage guidance and return format. Every part is necessary and front-loaded. No wasted words.
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?
Given 3 required parameters, no output schema, and no annotations, the description covers purpose, usage, behavior, and return fields (result, cortex_verdict, seal_hash). It also distinguishes between Omega Brain and external tools. Could mention error handling or alignment failure behavior, but overall sufficient for a wrapper tool.
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%, so baseline is 3. The description adds value by explaining the role of each parameter in context: 'tool' is the target Omega Brain tool name, 'args' may be steered by Cortex, and 'baseline' is for alignment check. This goes beyond the schema's individual descriptions.
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?
Description clearly defines tool as a Cortex-governed execution wrapper that checks alignment, steers, executes, and logs to SEAL chain. It distinguishes from siblings by specifying that it wraps Omega Brain tools (default invocation) while external tools are returned with steered_args for manual invocation. The verb 'wraps' and specific resource 'Omega Brain tools' make purpose unambiguous.
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?
Explicitly states 'Use this as the default way to invoke any Omega Brain tool with full governance' and clarifies that external tools are not executed but returned for manual invocation. This provides clear when-to-use and when-not-to-use guidance, effectively differentiating from sibling tools like omega_ingest or omega_rag_query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stores a new knowledge fragment in the provenance RAG store with source and evidence tier metadata. Use this to persist decisions, patterns, or findings for future retrieval via omega_rag_query. Returns JSON with fields: fragment_id, stored (boolean), timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Text content to store, e.g. 'Switched from Poetry to setuptools for pyproject.toml compatibility'. | |
| source | No | Origin identifier for provenance tracking, e.g. 'code-review', 'user-session', 'documentation'. | |
| tier | No | Evidence confidence tier: A (verified/reproducible), B (reliable), C (single source), D (unverified). | B |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses it stores and returns JSON with specific fields, but does not cover side effects like overwrite behavior, idempotency, or authorization requirements.
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?
Two concise sentences front-load the core action and return format. No extraneous text.
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?
Tool is simple with 3 parameters and no output schema. Description covers purpose, usage, and return fields. Could mention behavioral details like idempotency but overall sufficient.
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 baseline is 3. Description adds no extra meaning beyond the schema's parameter descriptions, which are already clear for content, source, and tier.
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?
The description clearly states the verb 'stores', the resource 'knowledge fragment in provenance RAG store', and the purpose 'persist for future retrieval via omega_rag_query', distinguishing it from retrieval tools like omega_rag_query.
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?
Explicitly advises when to use: 'persist decisions, patterns, or findings for future retrieval'. Does not include when-not-to-use or alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Writes a complete session record to the vault for cross-session persistence. Use this at the end of a work session to record what was done; data is retrievable via omega_vault_search. Returns JSON with fields: session_id, stored (boolean), entry_count (integer).
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | No | Unique session identifier. Auto-generated if omitted. | |
| task | Yes | Description of the task completed, e.g. 'Migrated database schema to v3'. | |
| decisions | No | Key decisions made, e.g. ['Used Alembic for migrations', 'Kept backward compatibility']. | |
| files_modified | No | File paths changed, e.g. ['src/models.py', 'alembic/versions/001.py']. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the tool writes persistent data, returns JSON with specific fields (session_id, stored, entry_count), and implies the operation is safe (no destructive actions mentioned). Could elaborate on overwrite/append behavior, but sufficient for a log tool.
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?
Two sentences that are front-loaded with purpose, followed by usage guidance and return value. No redundant information; every sentence earns its place.
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?
Given 4 parameters with full schema descriptions, a clear usage instruction, and declared return fields, the description is complete enough for the agent. Could include error handling, but the tool is straightforward and sibling tools are analytical, making this log tool well-defined.
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?
Input schema has 100% description coverage for all 4 parameters. The description adds no new meaning beyond the schema, only restating some fields. Baseline is 3 when schema is complete, and the description does not enhance parameter understanding.
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?
The description clearly states the tool writes a complete session record to the vault for cross-session persistence, using a specific verb and resource. It distinguishes itself from sibling omega_vault_search by noting data is retrievable via that tool, ensuring no ambiguity.
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?
The description explicitly instructs to use this tool at the end of a work session to record what was done, and mentions that data can be retrieved via omega_vault_search. This provides clear context for when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Loads episodic context for a new task by querying the RAG store, vault history, and any sealed handoff. Call this once at the start of every new task before doing any work. Returns JSON with fields: rag_matches, vault_history, handoff, continuity_type (CONTINUATION | CONTEXT_SWITCH | FRESH_START).
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Natural-language description of the task to load context for, e.g. 'Fix authentication bug in login module'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return format (fields like rag_matches, vault_history, handoff, continuity_type) and the call timing, but does not discuss side effects, idempotency, or error conditions. It is adequate but not rich.
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?
Two sentences, no waste. First sentence states purpose, second gives usage and return format. Front-loaded and efficient.
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?
Given a single parameter, no output schema, and no nested objects, the description covers the tool's action, parameters, return fields, and recommended call site. It is complete for the tool's simplicity, though it omits prerequisites like session state.
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% (the task parameter has a description). The description adds an example and specifies the type. This adds modest value beyond the schema, but does not compensate for missing parameter details like constraints.
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?
The description clearly states it 'Loads episodic context for a new task by querying the RAG store, vault history, and any sealed handoff.' This specific verb+resource combination distinguishes it from sibling tools like omega_rag_query or omega_vault_search.
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?
The description explicitly says 'Call this once at the start of every new task before doing any work,' providing clear context. It does not list conditions when not to use or alternatives, but the instruction is direct and sufficient for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches the provenance RAG store using semantic similarity and returns ranked text fragments. Use this for meaning-based search; use omega_vault_search instead for exact keyword matching. Returns JSON array of {fragment, similarity_score, quality_score, source, tier}.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural-language search query, e.g. 'How was the authentication module designed?'. | |
| top_k | No | Maximum number of results to return, between 1 and 50. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the search type (semantic similarity), return format (JSON array with specific fields), and implies read-only behavior. Could mention idempotency or side effects but is adequate for a search tool.
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?
Two sentences, front-loaded with action and resource, then usage and return structure. Every sentence adds value and no redundancy.
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?
For a simple search tool with well-described parameters and no output schema, the description fully specifies the return format (fragment, similarity_score, quality_score, source, tier). No gaps remain.
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?
Input schema covers 100% of parameters with descriptions. The description adds a natural-language query example and repeats the top_k range, but does not provide significant extra meaning beyond the schema. Baseline 3 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?
The description clearly states it searches a provenance RAG store using semantic similarity and returns ranked text fragments. It distinguishes itself from the sibling omega_vault_search, which does exact keyword matching.
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?
Explicitly states 'Use this for meaning-based search; use omega_vault_search instead for exact keyword matching.' This provides clear context for when to use this tool and an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Appends a tamper-proof entry to the SEAL (Secure Evidence Audit Ledger) SHA-256 hash chain. Use this to create an immutable audit record of significant events, decisions, or state changes. Returns JSON with fields: seal_hash (hex string), chain_position (integer), timestamp (ISO 8601).
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | Structured event metadata, e.g. {"action": "deploy", "target": "production", "version": "2.1.0"}. | |
| response | Yes | Outcome text to seal into the immutable ledger, e.g. 'Deployment succeeded with zero errors'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and clearly discloses traits: tamper-proof, immutable, and the exact return fields (seal_hash, chain_position, timestamp). It could also note that entries cannot be deleted or modified.
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?
Two sentences deliver maximum information with minimal words: action, purpose, and return details are front-loaded and efficiently stated.
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 lacking annotations and output schema, the description fully covers the tool's function, parameters, and return fields. For a simple 2-param tool, nothing essential 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 description adds only slight nuance (e.g., 'structured event metadata', 'outcome text to seal'), meeting the baseline but not significantly exceeding it.
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?
The description uses a specific verb ('appends') and resource ('SEAL... hash chain'), clearly distinguishing it from sibling tools like omega_brain_report or veritas_mis_greedy which serve different purposes.
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?
The description explicitly states when to use the tool ('to create an immutable audit record of significant events, decisions, or state changes'), but does not mention when not to use it or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches the vault database using exact keyword matching via SQLite FTS5. Use this for precise keyword lookups; use omega_rag_query instead for semantic/meaning-based search. Returns JSON array of matching vault entries with timestamps and session context.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | FTS5 keyword query supporting AND, OR, NOT, and quoted phrases, e.g. '"deploy production" NOT staging'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses use of FTS5, exact matching, and return format (JSON array with timestamps and session context). Does not mention authentication or side effects, but search is inherently read-only; still good for a search tool.
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?
Two sentences: first states purpose and method, second gives usage guidance and output format. No redundant words, highly efficient.
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?
Given one parameter and no output schema, the description covers purpose, method, usage guidance, and return format. It contrasts with a sibling tool. Complete for an agent to invoke correctly.
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 already explains FTS5 syntax (AND, OR, NOT, quotes). The description adds 'exact keyword matching' but does not provide additional meaning beyond the schema. Baseline score of 3 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?
Clearly states verb (searches), resource (vault database), and method (exact keyword matching via SQLite FTS5). Explicitly distinguishes from sibling tool omega_rag_query, making purpose unambiguous.
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?
Provides explicit guidance: use for precise keyword lookups, and directs to omega_rag_query for semantic search. This gives clear when-to-use and when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a SHA-256 sealed handoff document that auto-loads on the next server restart via omega://session/preload. Use this at the end of a session to ensure seamless context continuity for the next session. Returns JSON with fields: handoff_hash (hex string), file_path (string).
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Task title for the handoff, e.g. 'OAuth2 migration phase 2'. | |
| summary | Yes | Concise summary of progress and current state for the next session. | |
| decisions | No | Key decisions the next session should know about. | |
| files_modified | No | Files changed during this session. | |
| next_steps | No | Ordered list of recommended next actions. | |
| conversation_id | No | Optional external conversation tracking ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description carries full burden. It discloses the creation (write operation), the SHA-256 sealing, and the auto-load behavior on restart. However, it does not mention potential side effects or permissions.
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?
Three sentences with no extraneous information. Front-loaded with the primary action and key property (SHA-256 sealed handoff). Efficient and well-structured.
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?
The description explains the tool's purpose, usage timing, and return format. For a tool with 6 parameters and no output schema, it is fairly complete. Could mention error conditions, but overall adequate.
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%, so the schema already describes each parameter (task, summary, etc.). The description adds overall context but does not provide additional meaning beyond 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?
Description clearly states it creates a SHA-256 sealed handoff document that auto-loads on server restart. The specific verb 'creates', resource 'handoff document', and the unique URI 'omega://session/preload' make the purpose distinct from sibling tools like omega_seal_run or omega_log_session.
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?
Explicitly instructs to use 'at the end of a session to ensure seamless context continuity for the next session.' Provides clear when-to-use guidance, though it does not discuss alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gate 9/10: Stress-tests the claim against attack transforms (bound inflation, evidence removal, parameter/evidence perturbation). Use this as the final robustness check; fragility > 25% triggers MODEL_BOUND (ADVERSARY_FRAGILE). Returns JSON with verdict (PASS | MODEL_BOUND), fragility (float), attacks_tested (int), attacks_degraded (int).
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | A VERITAS BuildClaim object for deterministic gate evaluation. All fields are optional for partial evaluation — only fields relevant to the invoked gate are required. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Returns JSON with verdict, fragility, attacks_tested, attacks_degraded. Discloses threshold trigger. No annotations provided, so description adequately covers behavioral aspects.
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?
Two sentences: first defines purpose, second specifies usage and output. No filler, front-loaded with key information.
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?
Covers purpose, usage, output format. Lacks detailed explanation of attack transforms but overall complete for a gate tool given input schema richness.
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%; the description does not add extra parameter-specific meaning beyond what schema already provides. 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?
Description clearly states the tool 'stress-tests the claim against attack transforms' and labels it as the 'final robustness check', distinguishing it from sibling gate tools. The verb+resource combo is specific.
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?
Explicitly says 'Use this as the final robustness check' and specifies the fragility threshold. No explicit exclusions or alternatives named, but the context implies it's the last step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Maps a VERITAS verdict to a CLAEG terminal state: PASS→STABLE_CONTINUATION, MODEL_BOUND/INCONCLUSIVE→ISOLATED_CONTAINMENT, VIOLATION→TERMINAL_SHUTDOWN. Use this after a pipeline run to determine the system's required operational state. Returns JSON with fields: verdict (string), terminal_state (string), invariant (string).
| Name | Required | Description | Default |
|---|---|---|---|
| verdict | Yes | VERITAS verdict to resolve. Must be one of: PASS, MODEL_BOUND, INCONCLUSIVE, VIOLATION. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the return format (JSON with three fields) but does not state whether the tool has side effects or is read-only. The mapping is deterministic but the mutability is ambiguous.
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?
Two sentences: first maps verdicts to states, second gives usage and return format. Efficient and front-loaded, with no unnecessary words.
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?
For a simple tool with one enum parameter and no output schema, the description provides enough information (mapping, usage, return fields) to use correctly. No gaps apparent.
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% and the schema already describes the 'verdict' parameter with enum values. The description adds no additional semantic nuance beyond the schema, which is adequate for this single-parameter tool.
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?
The description clearly states the tool maps VERITAS verdicts to CLAEG terminal states with specific mappings, and identifies when to use it (after a pipeline run). However, it does not differentiate from the sibling tool veritas_claeg_transition, which likely has a similar purpose.
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?
The description provides usage context ('Use this after a pipeline run') but does not specify when not to use it or mention any alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates whether a CLAEG state transition is permitted under closed-world rules (absence of explicit permission = prohibition). Use this before changing system operational state; TERMINAL_SHUTDOWN is absorbing (no outbound transitions). Returns JSON with fields: allowed (boolean), reason (string).
| Name | Required | Description | Default |
|---|---|---|---|
| current_state | Yes | Current CLAEG state of the system. | |
| target_state | Yes | Desired target CLAEG state to transition to. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description fully explains behavior: it validates under closed-world rules, notes the absorbing state, and specifies the return format (allowed boolean and reason string). This is fully transparent.
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?
Two sentences, front-loaded with the core purpose, then usage guidance and return format. No wasted words.
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 no output schema, the description specifies the return fields (allowed, reason). It also covers the key rule about TERMINAL_SHUTDOWN absorbing, making it sufficient for safe invocation.
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 overall context (closed-world rules, absorbing state) but does not provide additional semantics for individual parameters beyond the schema's own descriptions.
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?
The description clearly states it validates CLAEG state transitions under closed-world rules, with a specific verb (validates) and resource (state transition). It also briefly distinguishes this as the validation step before changing state.
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?
Explicitly advises using this tool 'before changing system operational state' and highlights the important rule that TERMINAL_SHUTDOWN is absorbing. This provides clear context for when to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Computes the VERITAS Quality(e) score for a single evidence item using: clamp01(0.50provenance + 0.30uncertainty + 0.20*method). Use this to evaluate individual evidence quality before submitting to the evidence gate. Returns JSON with fields: quality (float 0.0-1.0).
| Name | Required | Description | Default |
|---|---|---|---|
| evidence_item | Yes | Evidence item with provenance (tier, source_id), method (protocol, repeatable), value (x, units, uncertainty), and timestamp. | |
| policy_env | No | Optional policy environment for match scoring. Defaults to empty. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It does not state whether the tool has side effects or requires specific permissions, but it clearly indicates it computes and returns a score without mentioning mutations.
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?
The description is three concise sentences—each serving a distinct purpose: formula, usage, and output. No redundancy or unnecessary information.
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?
Given no output schema, the description adequately describes the return format. It covers input requirements and usage context, making it complete for a straightforward computational tool.
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%, providing a baseline of 3. The description adds value by detailing nested fields expected in evidence_item (provenance, method, value, timestamp) and clarifies the role of policy_env, enriching understanding beyond 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?
The description clearly states the tool computes the VERITAS Quality score for a single evidence item, using a specific formula. It distinguishes from siblings like veritas_evidence_gate by positioning itself as a prerequisite step.
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?
The description explicitly advises using the tool to evaluate individual evidence quality before submitting to the evidence gate, providing clear context and a directive. It does not explicitly state when not to use alternatives, but the usage scenario is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gate 6/10: Computes resource utilization as max(cost_i / bound_i) and checks against redline thresholds. Use this to verify cost budgets are within limits; skipped automatically if no cost vector is declared. Returns JSON with verdict (PASS | MODEL_BOUND | INCONCLUSIVE), utilization (float), and reason_code: COST_OK, COST_REDLINING, COST_NOT_APPLICABLE, or UNDECLARED_COST_BOUND.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | A VERITAS BuildClaim object for deterministic gate evaluation. All fields are optional for partial evaluation — only fields relevant to the invoked gate are required. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully describes behavior: computes max(cost_i / bound_i), checks against redline thresholds, and returns verdicts and reason codes. It also notes that the gate is skipped when no cost vector is declared. This provides adequate transparency for an agent.
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?
The description is four sentences long and front-loads the core purpose. It includes all necessary information without being overly verbose. Could be slightly more concise, but it effectively communicates the essential 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?
Given that there is no output schema, the description explains the return format (verdict, utilization, reason_code) sufficiently. It also covers the key contextual detail about automatic skipping. The nested input schema is well-documented, so the description does not need to elaborate further.
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?
The input schema has 100% coverage with descriptions for each property of the 'claim' object. The description mentions 'cost vector' and 'cost bounds' which are part of the schema, but does not add significant meaning beyond what the schema already provides. Thus, it meets the baseline of 3.
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?
The description clearly identifies the tool as 'Gate 6/10' for computing resource utilization and checking against redline thresholds. It uses a specific verb ('computes', 'checks') and specifies the resource ('cost budgets'). The sibling context suggests it is distinct from other Veritas gates like evidence or security gates.
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?
The description states when to use: 'Use this to verify cost budgets are within limits' and when it is automatically skipped: 'skipped automatically if no cost vector is declared'. It does not explicitly mention alternatives among siblings, but the purpose is clear enough for an agent to differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gate 3/10: Analyzes supply-chain security via SBOM scan, CVE check, integrity verification, license compatibility, and dependency depth. Use this to assess third-party dependency risk before deploying or releasing. Returns JSON with verdict (PASS | MODEL_BOUND | VIOLATION) and per-dependency findings array.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | A VERITAS BuildClaim object for deterministic gate evaluation. All fields are optional for partial evaluation — only fields relevant to the invoked gate are required. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return format (JSON with verdict and findings) and mentions the checks performed. However, it does not state whether the operation is destructive, requires authentication, or has side effects. Annotations would have helped, but the description provides a reasonable behavioral overview.
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?
Two sentences: first states what it does and the gate number, second provides usage guidance and return summary. No wasted words, front-loaded with key information.
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?
The description is complete for the tool's complexity: it explains the gate function, usage, and return structure. No output schema, but return format is described. Slightly more detail about edge cases or failure modes would improve completeness.
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?
Input schema has one parameter 'claim' with 100% description coverage on all nested properties. The description reiterates the purpose but adds no novel parameter semantics beyond what the schema already provides. Baseline 3 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?
Description clearly states it's 'Gate 3/10' for analyzing supply-chain security via specific checks (SBOM scan, CVE check, etc.) and explicitly says 'Use this to assess third-party dependency risk before deploying or releasing.' It distinguishes from sibling gates (e.g., veritas_security_gate, veritas_adversary_gate).
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?
Description provides explicit usage context: 'Use this to assess third-party dependency risk before deploying or releasing.' It does not mention when not to use or name alternatives, but the context of sibling gates implies differentiation. Still, clear enough for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gate 4/10: Evaluates evidence sufficiency for critical variables by computing independence (MIS_GREEDY), agreement, and quality scores. Use this to verify that evidence meets K_min, A_min, Q_min thresholds; use veritas_compute_quality or veritas_mis_greedy for individual calculations. Returns JSON with verdict (PASS | INCONCLUSIVE) and reason_code: EVIDENCE_OK, INSUFFICIENT_INDEPENDENCE, LOW_AGREEMENT, or LOW_QUALITY.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | A VERITAS BuildClaim object for deterministic gate evaluation. All fields are optional for partial evaluation — only fields relevant to the invoked gate are required. | |
| regime | No | Threshold strictness: 'dev' (K=2, A=0.80, Q=0.70), 'staging' (same as dev), 'production' (K=3, A=0.90, Q=0.80). | dev |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes computation of independence, agreement, quality scores, and output format (verdict, reason_code). No annotations provided, so description carries full burden; lacks detail on side effects or prerequisites but is sufficient for a stateless evaluation tool.
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?
Three sentences, front-loaded with purpose, no wasted words.
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?
Covers purpose, usage, and output; with no output schema, it lists verdict and reason codes. Could mention the claim structure more but schema fills that gap.
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?
Adds context by explaining that the tool checks thresholds and provides output meanings; schema already has 100% coverage with detailed parameter descriptions, so the description complements rather than replaces.
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 specific verb ('evaluates evidence sufficiency'), resource ('critical variables'), and distinguishes from sibling tools by naming alternatives for individual calculations.
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?
Explicitly tells when to use this tool ('to verify thresholds') and when to use alternatives ('veritas_compute_quality or veritas_mis_greedy'), providing clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gate 7/10: Detects evidence monoculture by measuring source dominance (max_count_from_single_source / independent_set_size). Use this to guard against single-source bias in evidence; dominance > 0.50 triggers MODEL_BOUND. Returns JSON with verdict (PASS | MODEL_BOUND), dominance (float), and reason_code: INCENTIVE_OK or DOMINANCE_DETECTED.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | A VERITAS BuildClaim object for deterministic gate evaluation. All fields are optional for partial evaluation — only fields relevant to the invoked gate are required. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the tool's behavior: it returns JSON with verdict (PASS | MODEL_BOUND), dominance float, and reason_code. The threshold and trigger condition are clearly stated. No side effects are mentioned but the tool appears to be a pure computation.
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?
Two sentences concisely covering purpose, metric, threshold, effect, and return format. No fluff, front-loaded with the gate number and metric.
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?
Given the complex nested parameter and no output schema, the description adequately covers the gate's evaluation logic, return format, and triggering condition. It doesn't detail how claim fields are used, but the schema provides that.
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?
The input schema has 100% coverage with descriptions for all subfields of 'claim'. The tool description adds no additional meaning beyond the schema. Baseline score of 3 is appropriate as the schema already does the heavy lifting.
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?
The description clearly states it detects evidence monoculture by measuring source dominance with a specific metric (max_count_from_single_source / independent_set_size) and threshold (0.50). This distinguishes it from sibling gates like veritas_evidence_gate which likely handle evidence validation differently.
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?
The description explicitly says 'Use this to guard against single-source bias in evidence' and specifies the condition that triggers MODEL_BOUND. While it doesn't mention when not to use it or alternatives, the context of sibling gates implies appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gate 1/10: Parses, canonicalizes, and validates a BuildClaim's structure and computes SHA-256 IDs. Use this first to validate claim structure before running any downstream gates. Returns JSON with fields: verdict (PASS | VIOLATION), claim_id (hex), primitive_count (int), evidence_count (int).
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | A VERITAS BuildClaim object for deterministic gate evaluation. All fields are optional for partial evaluation — only fields relevant to the invoked gate are required. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It describes core behaviors (parsing, canonicalization, validation, ID computation) and specifies return fields (verdict, claim_id, etc.), but lacks details on edge cases like error handling or side effects. Still, it is largely transparent for a validation gate.
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?
The description is three sentences: function, usage instruction, and output format. It is front-loaded, efficient, and contains no superfluous text.
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?
Given the tool's complexity (nested object, no output schema), the description clearly explains the output JSON fields. However, it omits explicit handling of validation failures (e.g., VIOLATION verdict implications) and error scenarios, leaving minor completeness gaps.
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 schema already fully describes the 'claim' parameter and its nested fields. The description adds context about partial evaluation (only relevant fields required) but does not significantly augment parameter understanding beyond 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?
The description clearly states the tool's function: parsing, canonicalizing, and validating a BuildClaim's structure, with the explicit role as Gate 1/10. This distinguishes it from sibling gates by indicating it is the first step in the pipeline.
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?
The description explicitly instructs the agent to 'Use this first to validate claim structure before running any downstream gates,' providing clear when-to-use guidance and implying alternatives are other gates for later steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gate 5/10: Translates boundary constraints into interval arithmetic or SMT formulas and checks satisfiability with evidence values. Use this after evidence gate to verify that measured values satisfy all declared constraints. Returns JSON with verdict (PASS | VIOLATION | INCONCLUSIVE) and reason_code: MATH_OK, UNSAT_CONSTRAINT, or DECIDABILITY_TIMEOUT.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | A VERITAS BuildClaim object for deterministic gate evaluation. All fields are optional for partial evaluation — only fields relevant to the invoked gate are required. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It describes the translation and satisfiability check and discloses return values and reason codes, but does not cover side effects, limitations (beyond timeout), or input validation behavior.
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?
Three sentences, front-loaded with the core function, no unnecessary words. Every sentence adds value.
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?
The tool has one complex parameter and no output schema. The description explains purpose and output shape but does not clarify what happens if required fields are missing or provide examples. Given complexity, it is adequate but not complete.
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% (all properties have descriptions). The description adds no parameter-specific information beyond what the schema provides. Baseline 3 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?
The description clearly states the tool translates boundary constraints into interval arithmetic or SMT formulas and checks satisfiability with evidence values. It specifies it is 'Gate 5/10' and distinguishes from siblings by indicating use after the evidence gate.
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?
The description explicitly says 'Use this after evidence gate', providing clear context for when to invoke. It does not explicitly state when not to use, but the sequential hint is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs the MIS_GREEDY algorithm to find the maximum independent set of evidence items with no shared source, chain, dependency, or same-protocol-within-24h. Use this to check evidence independence before submitting to the evidence gate; use veritas_compute_quality for individual quality scores. Returns JSON with fields: independent_set (array), independent_count (int), total_items (int), agreement (float 0.0-1.0).
| Name | Required | Description | Default |
|---|---|---|---|
| evidence_items | Yes | Array of evidence items with id, variable, value, timestamp, method, provenance, and optional dependencies. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool returns JSON with specific fields (independent_set, independent_count, total_items, agreement). While it doesn't explicitly state that the tool is non-destructive or read-only, the context implies it's a computational algorithm with no side effects. A slight gap exists in not mentioning safety traits, but overall it's transparent.
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?
Three sentences, front-loaded with purpose, then usage guidelines, then output format. No wasted words; every sentence adds value. Very efficiently structured.
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?
Given one required parameter, no output schema, and no annotations, the description fully covers the tool's purpose, usage context, and return format. It is complete and leaves no critical gaps for an AI agent to understand when and how to invoke this tool.
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?
The schema coverage is 100% with one parameter, but the description adds meaning by specifying that evidence items should have fields like id, variable, value, timestamp, method, provenance, and optional dependencies. This goes beyond the generic schema description and helps the agent understand expected structure.
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?
The description clearly states the tool runs the MIS_GREEDY algorithm to find the maximum independent set of evidence items with constraints (shared source, chain, dependency, same-protocol-within-24h). It also distinguishes itself from siblings like veritas_compute_quality and veritas_evidence_gate by explaining when to use each, making the purpose very specific and well-differentiated.
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?
Explicitly states 'Use this to check evidence independence before submitting to the evidence gate; use veritas_compute_quality for individual quality scores.' This provides clear context on when to use this tool and when to use an alternative, which is excellent guidance for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scans text for NAFE failure signatures: Narrative Rescue, Moral Override, Authority Drift, and Intent Inference. Use this on commit messages, PR descriptions, or incident reports to detect narrative bypasses of deterministic gates. Returns JSON with fields: clean (boolean), flags (array of detected signatures), scan_metadata (object). Violations auto-seal to the audit ledger.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to scan for narrative failure signatures, e.g. a commit message or incident report. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses the return JSON structure and the side effect of auto-sealing violations to the audit ledger. It could mention whether the tool is read-only or have rate limits, but it covers the key behavioral aspects.
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?
Three sentences with no wasted words: first sentence states action and signatures, second gives usage and purpose, third covers output and side effect. Each sentence earns its place.
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?
The description covers purpose, usage, output format, and side effect. It compensates for the lack of output schema by listing the return fields. However, it doesn't mention size limits or error conditions, which would make it more complete.
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?
The single parameter 'text' is well-described in both the input schema and the main description, which adds examples (commit messages, incident reports) beyond the schema's brief example. This enriches the parameter meaning.
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?
The description explicitly states it scans text for four specific NAFE failure signatures, with a clear verb and resource. This distinguishes it from sibling tools, which are primarily gates or execution tools, making it a unique scanning/analysis tool.
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?
The description gives explicit context: 'Use this on commit messages, PR descriptions, or incident reports'. While it doesn't list alternatives or when not to use, the context effectively guides the agent to appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs the full 10-gate VERITAS pipeline: INTAKE → TYPE → DEPENDENCY → EVIDENCE → MATH → COST → INCENTIVE → SECURITY → ADVERSARY → TRACE/SEAL. Use this for complete end-to-end evaluation of a BuildClaim; use individual gates for targeted checks. Returns JSON with fields: final_verdict (PASS | MODEL_BOUND | INCONCLUSIVE | VIOLATION), gate_results (array), reason_codes (array), seal_hash (hex string).
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | A VERITAS BuildClaim object for deterministic gate evaluation. All fields are optional for partial evaluation — only fields relevant to the invoked gate are required. | |
| fail_fast | No | If true (default), halts on first VIOLATION. Set false to collect all gate verdicts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions it returns JSON with specific fields (final_verdict, gate_results, etc.), which is good. However, does not disclose potential side effects, authorization requirements, or runtime implications such as long execution time.
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?
Two concise sentences: first describes purpose and gates, second gives usage guidance and return format. No redundant or off-topic content. Front-loaded with essential information.
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?
Given the complexity (10 gates, large claim object), description covers purpose, usage distinction, and return structure. Lacks mention of prerequisites, order guarantees, or handling of errors. Output schema is not provided, so description compensates by listing return fields.
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 baseline is 3. Description does not add detail beyond schema parameter descriptions; it focuses on return format. Does not clarify edge cases like partial claim objects or default behavior of fail_fast.
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?
Clearly states it runs the full 10-gate VERITAS pipeline end-to-end for evaluating a BuildClaim, listing all gate names. Differentiates from sibling gate tools by specifying 'use individual gates for targeted checks'.
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?
Explicitly tells when to use this tool ('complete end-to-end evaluation') and when to use alternatives ('use individual gates for targeted checks'). Provides clear decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gate 8/10: Evaluates security posture from SAST, secret detection, injection surfaces, auth boundaries, and TLS config. Use this to enforce zero-tolerance security policy — any CRITICAL finding or exposed secret causes VIOLATION. Returns JSON with verdict (PASS | MODEL_BOUND | VIOLATION) and findings array with severity levels.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | A VERITAS BuildClaim object for deterministic gate evaluation. All fields are optional for partial evaluation — only fields relevant to the invoked gate are required. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the violation trigger (any CRITICAL finding or exposed secret) and return format (verdict with PASS/MODEL_BOUND/VIOLATION and findings). No side effects or permissions discussed.
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?
Three sentences, each serving a distinct purpose: purpose, usage, and return. No fluff, front-loaded with the primary action.
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?
Covers all essential aspects for a gate: what it evaluates, enforcement policy, verdict outcomes, and return type. No output schema exists, so describing the return format is sufficient.
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% for the single parameter 'claim', with detailed property descriptions. The description adds no additional parameter-level meaning beyond what the schema provides.
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?
The description clearly states the verb (evaluates), resource (security posture), and specific aspects (SAST, secret detection, etc.). It distinguishes itself as 'Gate 8/10' among sibling VERITAS gates.
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?
Explicitly says 'Use this to enforce zero-tolerance security policy', indicating when to use. Does not explicitly state when not to use or provide alternatives, but the context of being a security gate is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gate 2/10: Enforces type-level correctness — unique primitives, non-empty domains, operator arity, symbol resolution, and unit consistency. Use this after intake to catch structural errors before evidence evaluation. Returns JSON with verdict (PASS | VIOLATION) and reason_code: TYPE_OK, TYPE_DUPLICATE_PRIMITIVE, TYPE_EMPTY_DOMAIN, TYPE_OPERATOR_ARITY, UNDEFINED_SYMBOL, or UNIT_MISMATCH.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | A VERITAS BuildClaim object for deterministic gate evaluation. All fields are optional for partial evaluation — only fields relevant to the invoked gate are required. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, description discloses return format (JSON with verdict and reason_code) and enumerates all possible reason codes. No side effects or authorization details are given, but the primary behavioral trait (validation with structured output) is well-covered.
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?
Two compact sentences: first defines purpose and checks, second gives usage timing and return format. No wasted words, front-loaded with key information.
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?
Covers input structure, output format, and pipeline placement. Lacks explicit mention of prerequisite gates (e.g., intake), but the phrase 'after intake' implies it. Output schema is absent but description compensates with reason codes.
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?
Input schema has 100% coverage with rich descriptions, but the description adds value by noting that all claim fields are optional for partial evaluation and by listing the specific type checks performed, which is not in 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?
Description clearly states the tool enforces type-level correctness with specific checks (unique primitives, non-empty domains, operator arity, etc.) and positions it as Gate 2/10 in a pipeline, distinguishing it from sibling gates like intake or evidence.
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?
Explicitly says 'Use this after intake to catch structural errors before evidence evaluation', providing clear sequencing context among sibling pipeline tools. Does not list exclusions but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
omega_brain_reportomega_brain_statusomega_cortex_checkomega_cortex_steeromega_executeomega_ingestomega_log_sessionomega_preload_contextomega_rag_queryomega_seal_runomega_vault_searchomega_write_handoffveritas_adversary_gateveritas_claeg_resolveveritas_claeg_transitionveritas_compute_qualityveritas_cost_gateveritas_dependency_gateveritas_evidence_gateveritas_incentive_gateveritas_intake_gateveritas_math_gateveritas_mis_greedyveritas_nafe_scanveritas_run_pipelineveritas_security_gateveritas_type_gatev2.1.1omega_brain_reportomega_brain_statusomega_cortex_checkomega_cortex_steeromega_executeomega_ingestomega_log_sessionomega_preload_contextomega_rag_queryomega_seal_runomega_vault_searchomega_write_handoffveritas_adversary_gateveritas_claeg_resolveveritas_claeg_transitionveritas_compute_qualityveritas_cost_gateveritas_dependency_gateveritas_evidence_gateveritas_incentive_gateveritas_intake_gateveritas_math_gateveritas_mis_greedyveritas_nafe_scanveritas_run_pipelineveritas_security_gateveritas_type_gatev1.0.2omega_brain_report1 field changedInput schema / properties / lines / descriptionPrevious value: -"Number of recent SEAL ledger entries to include in the report. Higher values show more audit history."New value: +"Number of recent SEAL ledger entries to include, between 1 and 100."omega_cortex_check3 fields changedInput schema / properties / args / descriptionPrevious value: -"The arguments that will be passed to the tool. These are serialized and compared against the baseline for drift detection."New value: +"The proposed arguments for the tool call, serialized as a JSON object."Input schema / properties / baseline_prompt / descriptionPrevious value: -"The declared task baseline describing the intended operation. The Cortex measures semantic distance between this baseline and the tool+args to detect drift."New value: +"Task baseline describing the intended operation, e.g. 'Refactoring the auth module for OAuth2 support'."Input schema / properties / tool / descriptionPrevious value: -"The name of the tool being checked for alignment, e.g. 'omega_ingest' or 'veritas_run_pipeline'."New value: +"Name of the tool to check alignment for, e.g. 'omega_ingest'."omega_cortex_steer3 fields changedInput schema / properties / args / descriptionPrevious value: -"The original tool arguments that may be drifting from the baseline. These will be corrected if within steering range."New value: +"The original arguments that may be drifting from baseline. Will be corrected if in the steering range."Input schema / properties / baseline_prompt / descriptionPrevious value: -"The task baseline that defines the intended direction. Arguments are steered toward alignment with this baseline."New value: +"Task baseline to steer toward, e.g. 'Deploying hotfix to staging environment'."Input schema / properties / tool / descriptionPrevious value: -"The name of the tool whose arguments need steering, e.g. 'omega_ingest' or 'omega_seal_run'."New value: +"Name of the tool whose arguments may need correction, e.g. 'omega_seal_run'."omega_execute3 fields changedInput schema / properties / args / descriptionPrevious value: -"The arguments to pass to the target tool. These may be steered by the Cortex if they drift from the baseline."New value: +"Arguments for the target tool. May be steered by the Cortex before execution."Input schema / properties / baseline / descriptionPrevious value: -"Task baseline description for the Cortex alignment check. The Cortex measures semantic distance between this baseline and the tool+args."New value: +"Task baseline for the Cortex alignment check, e.g. 'Ingesting code review findings'."Input schema / properties / tool / descriptionPrevious value: -"The name of the Omega Brain tool to execute, e.g. 'omega_ingest', 'omega_rag_query', 'omega_seal_run'. Only Omega Brain tools can be dispatched through this wrapper."New value: +"Omega Brain tool name to execute, e.g. 'omega_ingest', 'omega_rag_query', 'omega_seal_run'."omega_ingest3 fields changedInput schema / properties / content / descriptionPrevious value: -"The text content to ingest into the RAG store. Can be any knowledge fragment: a decision rationale, code pattern, finding, or reference material."New value: +"Text content to store, e.g. 'Switched from Poetry to setuptools for pyproject.toml compatibility'."Input schema / properties / source / descriptionPrevious value: -"Identifier for the origin of this knowledge, e.g. 'user-session', 'code-review', 'documentation'. Used for provenance tracking and dominance analysis."New value: +"Origin identifier for provenance tracking, e.g. 'code-review', 'user-session', 'documentation'."Input schema / properties / tier / descriptionPrevious value: -"VERITAS evidence tier rating. A = highest confidence (verified, reproducible), B = high (reliable source), C = moderate (single source), D = low (unverified). Affects Quality(e) scoring."New value: +"Evidence confidence tier: A (verified/reproducible), B (reliable), C (single source), D (unverified)."omega_log_session4 fields changedInput schema / properties / decisions / descriptionPrevious value: -"List of key decisions made during the session, e.g. ['Used setuptools over poetry', 'Pinned dependency to v3.2.1']."New value: +"Key decisions made, e.g. ['Used Alembic for migrations', 'Kept backward compatibility']."Input schema / properties / files_modified / descriptionPrevious value: -"List of file paths that were created or modified during the session, e.g. ['src/main.py', 'pyproject.toml']."New value: +"File paths changed, e.g. ['src/models.py', 'alembic/versions/001.py']."Input schema / properties / session_id / descriptionPrevious value: -"Optional unique identifier for this session. If omitted, the current server session ID is used."New value: +"Unique session identifier. Auto-generated if omitted."Input schema / properties / task / descriptionPrevious value: -"Natural-language description of the task completed during this session."New value: +"Description of the task completed, e.g. 'Migrated database schema to v3'."omega_preload_context1 field changedInput schema / properties / task / descriptionPrevious value: -"A natural-language description of the task you are starting. This is used to query the RAG store for relevant prior knowledge and to classify context continuity."New value: +"Natural-language description of the task to load context for, e.g. 'Fix authentication bug in login module'."omega_rag_query2 fields changedInput schema / properties / query / descriptionPrevious value: -"Natural-language search query to match against stored knowledge fragments using semantic similarity."New value: +"Natural-language search query, e.g. 'How was the authentication module designed?'."Input schema / properties / top_k / descriptionPrevious value: -"Maximum number of ranked results to return. Higher values return more matches but may include lower-relevance fragments."New value: +"Maximum number of results to return, between 1 and 50."omega_seal_run2 fields changedInput schema / properties / context / descriptionPrevious value: -"Structured metadata for the seal entry. Should contain key-value pairs describing the event being recorded, e.g. {'action': 'deploy', 'target': 'production', 'version': '2.1.0'}."New value: +"Structured event metadata, e.g. {\"action\": \"deploy\", \"target\": \"production\", \"version\": \"2.1.0\"}."Input schema / properties / response / descriptionPrevious value: -"The response or outcome text to seal into the audit ledger. This becomes part of the immutable hash chain."New value: +"Outcome text to seal into the immutable ledger, e.g. 'Deployment succeeded with zero errors'."omega_vault_search1 field changedInput schema / properties / query / descriptionPrevious value: -"Keyword search query for full-text search. Supports SQLite FTS5 syntax: AND, OR, NOT, phrase matching with double quotes."New value: +"FTS5 keyword query supporting AND, OR, NOT, and quoted phrases, e.g. '\"deploy production\" NOT staging'."omega_write_handoff6 fields changedInput schema / properties / conversation_id / descriptionPrevious value: -"Optional conversation identifier for cross-referencing with external conversation tracking systems."New value: +"Optional external conversation tracking ID."Input schema / properties / decisions / descriptionPrevious value: -"Key architectural or implementation decisions that the next session should be aware of."New value: +"Key decisions the next session should know about."Input schema / properties / files_modified / descriptionPrevious value: -"Files that were changed during this session, so the next session knows what to review."New value: +"Files changed during this session."Input schema / properties / next_steps / descriptionPrevious value: -"Ordered list of recommended next actions for the continuation session."New value: +"Ordered list of recommended next actions."Input schema / properties / summary / descriptionPrevious value: -"Concise summary of what was accomplished and the current state. This is the primary context the next session will receive."New value: +"Concise summary of progress and current state for the next session."Input schema / properties / task / descriptionPrevious value: -"The task that was being worked on, used as the handoff title."New value: +"Task title for the handoff, e.g. 'OAuth2 migration phase 2'."veritas_adversary_gate16 fields changedInput schema / properties / claim / descriptionPrevious value: -"A VERITAS BuildClaim object containing all declared primitives, operators, regimes, boundaries, loss models, evidence items, cost vectors, and policy configuration needed for deterministic gate evaluation. All fields are optional for partial evaluation — only the fields relevant to the gate being invoked are required."New value: +"A VERITAS BuildClaim object for deterministic gate evaluation. All fields are optional for partial evaluation — only fields relevant to the invoked gate are required."Input schema / properties / claim / properties / attack_suite / descriptionPrevious value: -"AttackSuite with suite_id and list of Attack transforms (InflateBound, RemoveEvidence, PerturbParam, PerturbEvidence) for adversary gate."New value: +"Attack transforms for adversary testing: InflateBound, RemoveEvidence, PerturbParam, PerturbEvidence."Input schema / properties / claim / properties / boundaries / descriptionPrevious value: -"Named boundary constraints (e.g. 'CAPEX_USD <= 100000') that the claim must satisfy."New value: +"Boundary constraints, e.g. {name: 'cap', constraint: 'CAPEX_USD <= 100000'}."Input schema / properties / claim / properties / commit / descriptionPrevious value: -"Git commit SHA for reproducibility and audit trail."New value: +"Git commit SHA for reproducibility."Input schema / properties / claim / properties / cost / descriptionPrevious value: -"CostVector with optional fields: compute_flops, memory_bytes, wall_clock_s, capital_usd, coordination_agents."New value: +"CostVector: compute_flops, memory_bytes, wall_clock_s, capital_usd, coordination_agents."Input schema / properties / claim / properties / cost_bounds / descriptionPrevious value: -"Upper bounds for each cost component. Utilization = max(cost_i / bound_i). Values must be > 0."New value: +"Upper bounds for each cost component. All values must be > 0."Input schema / properties / claim / properties / dependencies / descriptionPrevious value: -"SBOM-style dependency manifest for supply-chain analysis: package names, versions, registries, and integrity hashes."New value: +"SBOM-style dependency manifest: package names, versions, registries, hashes."Input schema / properties / claim / properties / evidence / descriptionPrevious value: -"Evidence items, each with id, variable, value (Numeric or Categorical), timestamp, method, provenance, and optional dependencies."New value: +"Evidence items with id, variable, value, timestamp, method, provenance."Input schema / properties / claim / properties / loss_models / descriptionPrevious value: -"Named loss functions as ArithmeticExpr over primitives, with optional upper bounds."New value: +"Loss functions as ArithmeticExpr with optional upper bounds."Input schema / properties / claim / properties / operators / descriptionPrevious value: -"Declared operators with name, arity, input primitive names, output primitive name, and totality flag."New value: +"Operators with name, arity, input/output primitive names, totality flag."Input schema / properties / claim / properties / policy / descriptionPrevious value: -"PolicyConfig overrides: hash_alg, solver_backend, timeouts, thresholds. Defaults to VERITAS Omega v1.3.1 canonical values if omitted."New value: +"PolicyConfig overrides for hash_alg, solver_backend, timeouts, thresholds."Input schema / properties / claim / properties / primitives / descriptionPrevious value: -"Declared typed variables with name, domain (Interval/EnumSet/FiniteSet), optional units, and description."New value: +"Typed variables with name, domain (Interval/EnumSet/FiniteSet), optional units."Input schema / properties / claim / properties / project / descriptionPrevious value: -"Unique project identifier, e.g. 'omega-brain-mcp'."New value: +"Project identifier, e.g. 'omega-brain-mcp'."Input schema / properties / claim / properties / regimes / descriptionPrevious value: -"Named operating regimes, each with a predicate ConstraintExpr over declared primitives."New value: +"Operating regimes with name and predicate ConstraintExpr."Input schema / properties / claim / properties / security / descriptionPrevious value: -"Security posture declaration: SAST results, secret scan findings, injection surfaces, auth boundaries, and TLS/crypto configuration."New value: +"Security posture: SAST results, secret scan, injection surfaces, auth, TLS config."Input schema / properties / claim / properties / version / descriptionPrevious value: -"Semantic version string of the build being evaluated, e.g. '2.1.0'."New value: +"Semantic version, e.g. '2.1.0'."veritas_claeg_resolve1 field changedInput schema / properties / verdict / descriptionPrevious value: -"The VERITAS verdict to resolve into a CLAEG terminal state. Must be one of the four canonical verdict values."New value: +"VERITAS verdict to resolve. Must be one of: PASS, MODEL_BOUND, INCONCLUSIVE, VIOLATION."veritas_claeg_transition4 fields changedInput schema / properties / current_state / descriptionPrevious value: -"The current CLAEG state of the system, e.g. 'STABLE_CONTINUATION', 'ISOLATED_CONTAINMENT', or 'TERMINAL_SHUTDOWN'."New value: +"Current CLAEG state of the system."Input schema / properties / current_state / enumAdded value: +[
+ "STABLE_CONTINUATION",
+ "ISOLATED_CONTAINMENT",
+ "TERMINAL_SHUTDOWN"
+]Input schema / properties / target_state / descriptionPrevious value: -"The desired target CLAEG state to transition to. The validator checks if this transition is permitted."New value: +"Desired target CLAEG state to transition to."Input schema / properties / target_state / enumAdded value: +[
+ "STABLE_CONTINUATION",
+ "ISOLATED_CONTAINMENT",
+ "TERMINAL_SHUTDOWN"
+]veritas_compute_quality2 fields changedInput schema / properties / evidence_item / descriptionPrevious value: -"A single VERITAS evidence item containing at minimum: provenance (with tier and source_id), method (with protocol and repeatable flag), value (with x, units, and optional uncertainty), and timestamp."New value: +"Evidence item with provenance (tier, source_id), method (protocol, repeatable), value (x, units, uncertainty), and timestamp."Input schema / properties / policy_env / descriptionPrevious value: -"Optional policy environment specification for environment-match scoring. Defaults to empty object if omitted."New value: +"Optional policy environment for match scoring. Defaults to empty."veritas_cost_gate16 fields changedInput schema / properties / claim / descriptionPrevious value: -"A VERITAS BuildClaim object containing all declared primitives, operators, regimes, boundaries, loss models, evidence items, cost vectors, and policy configuration needed for deterministic gate evaluation. All fields are optional for partial evaluation — only the fields relevant to the gate being invoked are required."New value: +"A VERITAS BuildClaim object for deterministic gate evaluation. All fields are optional for partial evaluation — only fields relevant to the invoked gate are required."Input schema / properties / claim / properties / attack_suite / descriptionPrevious value: -"AttackSuite with suite_id and list of Attack transforms (InflateBound, RemoveEvidence, PerturbParam, PerturbEvidence) for adversary gate."New value: +"Attack transforms for adversary testing: InflateBound, RemoveEvidence, PerturbParam, PerturbEvidence."Input schema / properties / claim / properties / boundaries / descriptionPrevious value: -"Named boundary constraints (e.g. 'CAPEX_USD <= 100000') that the claim must satisfy."New value: +"Boundary constraints, e.g. {name: 'cap', constraint: 'CAPEX_USD <= 100000'}."Input schema / properties / claim / properties / commit / descriptionPrevious value: -"Git commit SHA for reproducibility and audit trail."New value: +"Git commit SHA for reproducibility."Input schema / properties / claim / properties / cost / descriptionPrevious value: -"CostVector with optional fields: compute_flops, memory_bytes, wall_clock_s, capital_usd, coordination_agents."New value: +"CostVector: compute_flops, memory_bytes, wall_clock_s, capital_usd, coordination_agents."Input schema / properties / claim / properties / cost_bounds / descriptionPrevious value: -"Upper bounds for each cost component. Utilization = max(cost_i / bound_i). Values must be > 0."New value: +"Upper bounds for each cost component. All values must be > 0."Input schema / properties / claim / properties / dependencies / descriptionPrevious value: -"SBOM-style dependency manifest for supply-chain analysis: package names, versions, registries, and integrity hashes."New value: +"SBOM-style dependency manifest: package names, versions, registries, hashes."Input schema / properties / claim / properties / evidence / descriptionPrevious value: -"Evidence items, each with id, variable, value (Numeric or Categorical), timestamp, method, provenance, and optional dependencies."New value: +"Evidence items with id, variable, value, timestamp, method, provenance."Input schema / properties / claim / properties / loss_models / descriptionPrevious value: -"Named loss functions as ArithmeticExpr over primitives, with optional upper bounds."New value: +"Loss functions as ArithmeticExpr with optional upper bounds."Input schema / properties / claim / properties / operators / descriptionPrevious value: -"Declared operators with name, arity, input primitive names, output primitive name, and totality flag."New value: +"Operators with name, arity, input/output primitive names, totality flag."Input schema / properties / claim / properties / policy / descriptionPrevious value: -"PolicyConfig overrides: hash_alg, solver_backend, timeouts, thresholds. Defaults to VERITAS Omega v1.3.1 canonical values if omitted."New value: +"PolicyConfig overrides for hash_alg, solver_backend, timeouts, thresholds."Input schema / properties / claim / properties / primitives / descriptionPrevious value: -"Declared typed variables with name, domain (Interval/EnumSet/FiniteSet), optional units, and description."New value: +"Typed variables with name, domain (Interval/EnumSet/FiniteSet), optional units."Input schema / properties / claim / properties / project / descriptionPrevious value: -"Unique project identifier, e.g. 'omega-brain-mcp'."New value: +"Project identifier, e.g. 'omega-brain-mcp'."Input schema / properties / claim / properties / regimes / descriptionPrevious value: -"Named operating regimes, each with a predicate ConstraintExpr over declared primitives."New value: +"Operating regimes with name and predicate ConstraintExpr."Input schema / properties / claim / properties / security / descriptionPrevious value: -"Security posture declaration: SAST results, secret scan findings, injection surfaces, auth boundaries, and TLS/crypto configuration."New value: +"Security posture: SAST results, secret scan, injection surfaces, auth, TLS config."Input schema / properties / claim / properties / version / descriptionPrevious value: -"Semantic version string of the build being evaluated, e.g. '2.1.0'."New value: +"Semantic version, e.g. '2.1.0'."veritas_dependency_gate16 fields changedInput schema / properties / claim / descriptionPrevious value: -"A VERITAS BuildClaim object containing all declared primitives, operators, regimes, boundaries, loss models, evidence items, cost vectors, and policy configuration needed for deterministic gate evaluation. All fields are optional for partial evaluation — only the fields relevant to the gate being invoked are required."New value: +"A VERITAS BuildClaim object for deterministic gate evaluation. All fields are optional for partial evaluation — only fields relevant to the invoked gate are required."Input schema / properties / claim / properties / attack_suite / descriptionPrevious value: -"AttackSuite with suite_id and list of Attack transforms (InflateBound, RemoveEvidence, PerturbParam, PerturbEvidence) for adversary gate."New value: +"Attack transforms for adversary testing: InflateBound, RemoveEvidence, PerturbParam, PerturbEvidence."Input schema / properties / claim / properties / boundaries / descriptionPrevious value: -"Named boundary constraints (e.g. 'CAPEX_USD <= 100000') that the claim must satisfy."New value: +"Boundary constraints, e.g. {name: 'cap', constraint: 'CAPEX_USD <= 100000'}."Input schema / properties / claim / properties / commit / descriptionPrevious value: -"Git commit SHA for reproducibility and audit trail."New value: +"Git commit SHA for reproducibility."Input schema / properties / claim / properties / cost / descriptionPrevious value: -"CostVector with optional fields: compute_flops, memory_bytes, wall_clock_s, capital_usd, coordination_agents."New value: +"CostVector: compute_flops, memory_bytes, wall_clock_s, capital_usd, coordination_agents."Input schema / properties / claim / properties / cost_bounds / descriptionPrevious value: -"Upper bounds for each cost component. Utilization = max(cost_i / bound_i). Values must be > 0."New value: +"Upper bounds for each cost component. All values must be > 0."Input schema / properties / claim / properties / dependencies / descriptionPrevious value: -"SBOM-style dependency manifest for supply-chain analysis: package names, versions, registries, and integrity hashes."New value: +"SBOM-style dependency manifest: package names, versions, registries, hashes."Input schema / properties / claim / properties / evidence / descriptionPrevious value: -"Evidence items, each with id, variable, value (Numeric or Categorical), timestamp, method, provenance, and optional dependencies."New value: +"Evidence items with id, variable, value, timestamp, method, provenance."Input schema / properties / claim / properties / loss_models / descriptionPrevious value: -"Named loss functions as ArithmeticExpr over primitives, with optional upper bounds."New value: +"Loss functions as ArithmeticExpr with optional upper bounds."Input schema / properties / claim / properties / operators / descriptionPrevious value: -"Declared operators with name, arity, input primitive names, output primitive name, and totality flag."New value: +"Operators with name, arity, input/output primitive names, totality flag."Input schema / properties / claim / properties / policy / descriptionPrevious value: -"PolicyConfig overrides: hash_alg, solver_backend, timeouts, thresholds. Defaults to VERITAS Omega v1.3.1 canonical values if omitted."New value: +"PolicyConfig overrides for hash_alg, solver_backend, timeouts, thresholds."Input schema / properties / claim / properties / primitives / descriptionPrevious value: -"Declared typed variables with name, domain (Interval/EnumSet/FiniteSet), optional units, and description."New value: +"Typed variables with name, domain (Interval/EnumSet/FiniteSet), optional units."Input schema / properties / claim / properties / project / descriptionPrevious value: -"Unique project identifier, e.g. 'omega-brain-mcp'."New value: +"Project identifier, e.g. 'omega-brain-mcp'."Input schema / properties / claim / properties / regimes / descriptionPrevious value: -"Named operating regimes, each with a predicate ConstraintExpr over declared primitives."New value: +"Operating regimes with name and predicate ConstraintExpr."Input schema / properties / claim / properties / security / descriptionPrevious value: -"Security posture declaration: SAST results, secret scan findings, injection surfaces, auth boundaries, and TLS/crypto configuration."New value: +"Security posture: SAST results, secret scan, injection surfaces, auth, TLS config."Input schema / properties / claim / properties / version / descriptionPrevious value: -"Semantic version string of the build being evaluated, e.g. '2.1.0'."New value: +"Semantic version, e.g. '2.1.0'."veritas_evidence_gate17 fields changedInput schema / properties / claim / descriptionPrevious value: -"A VERITAS BuildClaim object containing all declared primitives, operators, regimes, boundaries, loss models, evidence items, cost vectors, and policy configuration needed for deterministic gate evaluation. All fields are optional for partial evaluation — only the fields relevant to the gate being invoked are required."New value: +"A VERITAS BuildClaim object for deterministic gate evaluation. All fields are optional for partial evaluation — only fields relevant to the invoked gate are required."Input schema / properties / claim / properties / attack_suite / descriptionPrevious value: -"AttackSuite with suite_id and list of Attack transforms (InflateBound, RemoveEvidence, PerturbParam, PerturbEvidence) for adversary gate."New value: +"Attack transforms for adversary testing: InflateBound, RemoveEvidence, PerturbParam, PerturbEvidence."Input schema / properties / claim / properties / boundaries / descriptionPrevious value: -"Named boundary constraints (e.g. 'CAPEX_USD <= 100000') that the claim must satisfy."New value: +"Boundary constraints, e.g. {name: 'cap', constraint: 'CAPEX_USD <= 100000'}."Input schema / properties / claim / properties / commit / descriptionPrevious value: -"Git commit SHA for reproducibility and audit trail."New value: +"Git commit SHA for reproducibility."Input schema / properties / claim / properties / cost / descriptionPrevious value: -"CostVector with optional fields: compute_flops, memory_bytes, wall_clock_s, capital_usd, coordination_agents."New value: +"CostVector: compute_flops, memory_bytes, wall_clock_s, capital_usd, coordination_agents."Input schema / properties / claim / properties / cost_bounds / descriptionPrevious value: -"Upper bounds for each cost component. Utilization = max(cost_i / bound_i). Values must be > 0."New value: +"Upper bounds for each cost component. All values must be > 0."Input schema / properties / claim / properties / dependencies / descriptionPrevious value: -"SBOM-style dependency manifest for supply-chain analysis: package names, versions, registries, and integrity hashes."New value: +"SBOM-style dependency manifest: package names, versions, registries, hashes."Input schema / properties / claim / properties / evidence / descriptionPrevious value: -"Evidence items, each with id, variable, value (Numeric or Categorical), timestamp, method, provenance, and optional dependencies."New value: +"Evidence items with id, variable, value, timestamp, method, provenance."Input schema / properties / claim / properties / loss_models / descriptionPrevious value: -"Named loss functions as ArithmeticExpr over primitives, with optional upper bounds."New value: +"Loss functions as ArithmeticExpr with optional upper bounds."Input schema / properties / claim / properties / operators / descriptionPrevious value: -"Declared operators with name, arity, input primitive names, output primitive name, and totality flag."New value: +"Operators with name, arity, input/output primitive names, totality flag."Input schema / properties / claim / properties / policy / descriptionPrevious value: -"PolicyConfig overrides: hash_alg, solver_backend, timeouts, thresholds. Defaults to VERITAS Omega v1.3.1 canonical values if omitted."New value: +"PolicyConfig overrides for hash_alg, solver_backend, timeouts, thresholds."Input schema / properties / claim / properties / primitives / descriptionPrevious value: -"Declared typed variables with name, domain (Interval/EnumSet/FiniteSet), optional units, and description."New value: +"Typed variables with name, domain (Interval/EnumSet/FiniteSet), optional units."Input schema / properties / claim / properties / project / descriptionPrevious value: -"Unique project identifier, e.g. 'omega-brain-mcp'."New value: +"Project identifier, e.g. 'omega-brain-mcp'."Input schema / properties / claim / properties / regimes / descriptionPrevious value: -"Named operating regimes, each with a predicate ConstraintExpr over declared primitives."New value: +"Operating regimes with name and predicate ConstraintExpr."Input schema / properties / claim / properties / security / descriptionPrevious value: -"Security posture declaration: SAST results, secret scan findings, injection surfaces, auth boundaries, and TLS/crypto configuration."New value: +"Security posture: SAST results, secret scan, injection surfaces, auth, TLS config."Input schema / properties / claim / properties / version / descriptionPrevious value: -"Semantic version string of the build being evaluated, e.g. '2.1.0'."New value: +"Semantic version, e.g. '2.1.0'."Input schema / properties / regime / descriptionPrevious value: -"Build regime that determines evidence threshold strictness. 'dev' uses baseline thresholds (K=2, A=0.80, Q=0.70), 'production' uses escalated irreversibility thresholds (K=3, A=0.90, Q=0.80)."New value: +"Threshold strictness: 'dev' (K=2, A=0.80, Q=0.70), 'staging' (same as dev), 'production' (K=3, A=0.90, Q=0.80)."veritas_incentive_gate16 fields changedInput schema / properties / claim / descriptionPrevious value: -"A VERITAS BuildClaim object containing all declared primitives, operators, regimes, boundaries, loss models, evidence items, cost vectors, and policy configuration needed for deterministic gate evaluation. All fields are optional for partial evaluation — only the fields relevant to the gate being invoked are required."New value: +"A VERITAS BuildClaim object for deterministic gate evaluation. All fields are optional for partial evaluation — only fields relevant to the invoked gate are required."Input schema / properties / claim / properties / attack_suite / descriptionPrevious value: -"AttackSuite with suite_id and list of Attack transforms (InflateBound, RemoveEvidence, PerturbParam, PerturbEvidence) for adversary gate."New value: +"Attack transforms for adversary testing: InflateBound, RemoveEvidence, PerturbParam, PerturbEvidence."Input schema / properties / claim / properties / boundaries / descriptionPrevious value: -"Named boundary constraints (e.g. 'CAPEX_USD <= 100000') that the claim must satisfy."New value: +"Boundary constraints, e.g. {name: 'cap', constraint: 'CAPEX_USD <= 100000'}."Input schema / properties / claim / properties / commit / descriptionPrevious value: -"Git commit SHA for reproducibility and audit trail."New value: +"Git commit SHA for reproducibility."Input schema / properties / claim / properties / cost / descriptionPrevious value: -"CostVector with optional fields: compute_flops, memory_bytes, wall_clock_s, capital_usd, coordination_agents."New value: +"CostVector: compute_flops, memory_bytes, wall_clock_s, capital_usd, coordination_agents."Input schema / properties / claim / properties / cost_bounds / descriptionPrevious value: -"Upper bounds for each cost component. Utilization = max(cost_i / bound_i). Values must be > 0."New value: +"Upper bounds for each cost component. All values must be > 0."Input schema / properties / claim / properties / dependencies / descriptionPrevious value: -"SBOM-style dependency manifest for supply-chain analysis: package names, versions, registries, and integrity hashes."New value: +"SBOM-style dependency manifest: package names, versions, registries, hashes."Input schema / properties / claim / properties / evidence / descriptionPrevious value: -"Evidence items, each with id, variable, value (Numeric or Categorical), timestamp, method, provenance, and optional dependencies."New value: +"Evidence items with id, variable, value, timestamp, method, provenance."Input schema / properties / claim / properties / loss_models / descriptionPrevious value: -"Named loss functions as ArithmeticExpr over primitives, with optional upper bounds."New value: +"Loss functions as ArithmeticExpr with optional upper bounds."Input schema / properties / claim / properties / operators / descriptionPrevious value: -"Declared operators with name, arity, input primitive names, output primitive name, and totality flag."New value: +"Operators with name, arity, input/output primitive names, totality flag."Input schema / properties / claim / properties / policy / descriptionPrevious value: -"PolicyConfig overrides: hash_alg, solver_backend, timeouts, thresholds. Defaults to VERITAS Omega v1.3.1 canonical values if omitted."New value: +"PolicyConfig overrides for hash_alg, solver_backend, timeouts, thresholds."Input schema / properties / claim / properties / primitives / descriptionPrevious value: -"Declared typed variables with name, domain (Interval/EnumSet/FiniteSet), optional units, and description."New value: +"Typed variables with name, domain (Interval/EnumSet/FiniteSet), optional units."Input schema / properties / claim / properties / project / descriptionPrevious value: -"Unique project identifier, e.g. 'omega-brain-mcp'."New value: +"Project identifier, e.g. 'omega-brain-mcp'."Input schema / properties / claim / properties / regimes / descriptionPrevious value: -"Named operating regimes, each with a predicate ConstraintExpr over declared primitives."New value: +"Operating regimes with name and predicate ConstraintExpr."Input schema / properties / claim / properties / security / descriptionPrevious value: -"Security posture declaration: SAST results, secret scan findings, injection surfaces, auth boundaries, and TLS/crypto configuration."New value: +"Security posture: SAST results, secret scan, injection surfaces, auth, TLS config."Input schema / properties / claim / properties / version / descriptionPrevious value: -"Semantic version string of the build being evaluated, e.g. '2.1.0'."New value: +"Semantic version, e.g. '2.1.0'."veritas_intake_gate16 fields changedInput schema / properties / claim / descriptionPrevious value: -"A VERITAS BuildClaim object containing all declared primitives, operators, regimes, boundaries, loss models, evidence items, cost vectors, and policy configuration needed for deterministic gate evaluation. All fields are optional for partial evaluation — only the fields relevant to the gate being invoked are required."New value: +"A VERITAS BuildClaim object for deterministic gate evaluation. All fields are optional for partial evaluation — only fields relevant to the invoked gate are required."Input schema / properties / claim / properties / attack_suite / descriptionPrevious value: -"AttackSuite with suite_id and list of Attack transforms (InflateBound, RemoveEvidence, PerturbParam, PerturbEvidence) for adversary gate."New value: +"Attack transforms for adversary testing: InflateBound, RemoveEvidence, PerturbParam, PerturbEvidence."Input schema / properties / claim / properties / boundaries / descriptionPrevious value: -"Named boundary constraints (e.g. 'CAPEX_USD <= 100000') that the claim must satisfy."New value: +"Boundary constraints, e.g. {name: 'cap', constraint: 'CAPEX_USD <= 100000'}."Input schema / properties / claim / properties / commit / descriptionPrevious value: -"Git commit SHA for reproducibility and audit trail."New value: +"Git commit SHA for reproducibility."Input schema / properties / claim / properties / cost / descriptionPrevious value: -"CostVector with optional fields: compute_flops, memory_bytes, wall_clock_s, capital_usd, coordination_agents."New value: +"CostVector: compute_flops, memory_bytes, wall_clock_s, capital_usd, coordination_agents."Input schema / properties / claim / properties / cost_bounds / descriptionPrevious value: -"Upper bounds for each cost component. Utilization = max(cost_i / bound_i). Values must be > 0."New value: +"Upper bounds for each cost component. All values must be > 0."Input schema / properties / claim / properties / dependencies / descriptionPrevious value: -"SBOM-style dependency manifest for supply-chain analysis: package names, versions, registries, and integrity hashes."New value: +"SBOM-style dependency manifest: package names, versions, registries, hashes."Input schema / properties / claim / properties / evidence / descriptionPrevious value: -"Evidence items, each with id, variable, value (Numeric or Categorical), timestamp, method, provenance, and optional dependencies."New value: +"Evidence items with id, variable, value, timestamp, method, provenance."Input schema / properties / claim / properties / loss_models / descriptionPrevious value: -"Named loss functions as ArithmeticExpr over primitives, with optional upper bounds."New value: +"Loss functions as ArithmeticExpr with optional upper bounds."Input schema / properties / claim / properties / operators / descriptionPrevious value: -"Declared operators with name, arity, input primitive names, output primitive name, and totality flag."New value: +"Operators with name, arity, input/output primitive names, totality flag."Input schema / properties / claim / properties / policy / descriptionPrevious value: -"PolicyConfig overrides: hash_alg, solver_backend, timeouts, thresholds. Defaults to VERITAS Omega v1.3.1 canonical values if omitted."New value: +"PolicyConfig overrides for hash_alg, solver_backend, timeouts, thresholds."Input schema / properties / claim / properties / primitives / descriptionPrevious value: -"Declared typed variables with name, domain (Interval/EnumSet/FiniteSet), optional units, and description."New value: +"Typed variables with name, domain (Interval/EnumSet/FiniteSet), optional units."Input schema / properties / claim / properties / project / descriptionPrevious value: -"Unique project identifier, e.g. 'omega-brain-mcp'."New value: +"Project identifier, e.g. 'omega-brain-mcp'."Input schema / properties / claim / properties / regimes / descriptionPrevious value: -"Named operating regimes, each with a predicate ConstraintExpr over declared primitives."New value: +"Operating regimes with name and predicate ConstraintExpr."Input schema / properties / claim / properties / security / descriptionPrevious value: -"Security posture declaration: SAST results, secret scan findings, injection surfaces, auth boundaries, and TLS/crypto configuration."New value: +"Security posture: SAST results, secret scan, injection surfaces, auth, TLS config."Input schema / properties / claim / properties / version / descriptionPrevious value: -"Semantic version string of the build being evaluated, e.g. '2.1.0'."New value: +"Semantic version, e.g. '2.1.0'."veritas_math_gate16 fields changedInput schema / properties / claim / descriptionPrevious value: -"A VERITAS BuildClaim object containing all declared primitives, operators, regimes, boundaries, loss models, evidence items, cost vectors, and policy configuration needed for deterministic gate evaluation. All fields are optional for partial evaluation — only the fields relevant to the gate being invoked are required."New value: +"A VERITAS BuildClaim object for deterministic gate evaluation. All fields are optional for partial evaluation — only fields relevant to the invoked gate are required."Input schema / properties / claim / properties / attack_suite / descriptionPrevious value: -"AttackSuite with suite_id and list of Attack transforms (InflateBound, RemoveEvidence, PerturbParam, PerturbEvidence) for adversary gate."New value: +"Attack transforms for adversary testing: InflateBound, RemoveEvidence, PerturbParam, PerturbEvidence."Input schema / properties / claim / properties / boundaries / descriptionPrevious value: -"Named boundary constraints (e.g. 'CAPEX_USD <= 100000') that the claim must satisfy."New value: +"Boundary constraints, e.g. {name: 'cap', constraint: 'CAPEX_USD <= 100000'}."Input schema / properties / claim / properties / commit / descriptionPrevious value: -"Git commit SHA for reproducibility and audit trail."New value: +"Git commit SHA for reproducibility."Input schema / properties / claim / properties / cost / descriptionPrevious value: -"CostVector with optional fields: compute_flops, memory_bytes, wall_clock_s, capital_usd, coordination_agents."New value: +"CostVector: compute_flops, memory_bytes, wall_clock_s, capital_usd, coordination_agents."Input schema / properties / claim / properties / cost_bounds / descriptionPrevious value: -"Upper bounds for each cost component. Utilization = max(cost_i / bound_i). Values must be > 0."New value: +"Upper bounds for each cost component. All values must be > 0."Input schema / properties / claim / properties / dependencies / descriptionPrevious value: -"SBOM-style dependency manifest for supply-chain analysis: package names, versions, registries, and integrity hashes."New value: +"SBOM-style dependency manifest: package names, versions, registries, hashes."Input schema / properties / claim / properties / evidence / descriptionPrevious value: -"Evidence items, each with id, variable, value (Numeric or Categorical), timestamp, method, provenance, and optional dependencies."New value: +"Evidence items with id, variable, value, timestamp, method, provenance."Input schema / properties / claim / properties / loss_models / descriptionPrevious value: -"Named loss functions as ArithmeticExpr over primitives, with optional upper bounds."New value: +"Loss functions as ArithmeticExpr with optional upper bounds."Input schema / properties / claim / properties / operators / descriptionPrevious value: -"Declared operators with name, arity, input primitive names, output primitive name, and totality flag."New value: +"Operators with name, arity, input/output primitive names, totality flag."Input schema / properties / claim / properties / policy / descriptionPrevious value: -"PolicyConfig overrides: hash_alg, solver_backend, timeouts, thresholds. Defaults to VERITAS Omega v1.3.1 canonical values if omitted."New value: +"PolicyConfig overrides for hash_alg, solver_backend, timeouts, thresholds."Input schema / properties / claim / properties / primitives / descriptionPrevious value: -"Declared typed variables with name, domain (Interval/EnumSet/FiniteSet), optional units, and description."New value: +"Typed variables with name, domain (Interval/EnumSet/FiniteSet), optional units."Input schema / properties / claim / properties / project / descriptionPrevious value: -"Unique project identifier, e.g. 'omega-brain-mcp'."New value: +"Project identifier, e.g. 'omega-brain-mcp'."Input schema / properties / claim / properties / regimes / descriptionPrevious value: -"Named operating regimes, each with a predicate ConstraintExpr over declared primitives."New value: +"Operating regimes with name and predicate ConstraintExpr."Input schema / properties / claim / properties / security / descriptionPrevious value: -"Security posture declaration: SAST results, secret scan findings, injection surfaces, auth boundaries, and TLS/crypto configuration."New value: +"Security posture: SAST results, secret scan, injection surfaces, auth, TLS config."Input schema / properties / claim / properties / version / descriptionPrevious value: -"Semantic version string of the build being evaluated, e.g. '2.1.0'."New value: +"Semantic version, e.g. '2.1.0'."veritas_mis_greedy1 field changedInput schema / properties / evidence_items / descriptionPrevious value: -"Array of VERITAS evidence items to analyze for independence. Each item should have id, variable, value, timestamp, method, provenance, and optional dependencies."New value: +"Array of evidence items with id, variable, value, timestamp, method, provenance, and optional dependencies."veritas_nafe_scan1 field changedInput schema / properties / text / descriptionPrevious value: -"The text content to scan for NAFE failure signatures. Can be a commit message, PR description, incident report, or any narrative text that might attempt to bypass deterministic gate verdicts."New value: +"Text to scan for narrative failure signatures, e.g. a commit message or incident report."veritas_run_pipeline17 fields changedInput schema / properties / claim / descriptionPrevious value: -"A VERITAS BuildClaim object containing all declared primitives, operators, regimes, boundaries, loss models, evidence items, cost vectors, and policy configuration needed for deterministic gate evaluation. All fields are optional for partial evaluation — only the fields relevant to the gate being invoked are required."New value: +"A VERITAS BuildClaim object for deterministic gate evaluation. All fields are optional for partial evaluation — only fields relevant to the invoked gate are required."Input schema / properties / claim / properties / attack_suite / descriptionPrevious value: -"AttackSuite with suite_id and list of Attack transforms (InflateBound, RemoveEvidence, PerturbParam, PerturbEvidence) for adversary gate."New value: +"Attack transforms for adversary testing: InflateBound, RemoveEvidence, PerturbParam, PerturbEvidence."Input schema / properties / claim / properties / boundaries / descriptionPrevious value: -"Named boundary constraints (e.g. 'CAPEX_USD <= 100000') that the claim must satisfy."New value: +"Boundary constraints, e.g. {name: 'cap', constraint: 'CAPEX_USD <= 100000'}."Input schema / properties / claim / properties / commit / descriptionPrevious value: -"Git commit SHA for reproducibility and audit trail."New value: +"Git commit SHA for reproducibility."Input schema / properties / claim / properties / cost / descriptionPrevious value: -"CostVector with optional fields: compute_flops, memory_bytes, wall_clock_s, capital_usd, coordination_agents."New value: +"CostVector: compute_flops, memory_bytes, wall_clock_s, capital_usd, coordination_agents."Input schema / properties / claim / properties / cost_bounds / descriptionPrevious value: -"Upper bounds for each cost component. Utilization = max(cost_i / bound_i). Values must be > 0."New value: +"Upper bounds for each cost component. All values must be > 0."Input schema / properties / claim / properties / dependencies / descriptionPrevious value: -"SBOM-style dependency manifest for supply-chain analysis: package names, versions, registries, and integrity hashes."New value: +"SBOM-style dependency manifest: package names, versions, registries, hashes."Input schema / properties / claim / properties / evidence / descriptionPrevious value: -"Evidence items, each with id, variable, value (Numeric or Categorical), timestamp, method, provenance, and optional dependencies."New value: +"Evidence items with id, variable, value, timestamp, method, provenance."Input schema / properties / claim / properties / loss_models / descriptionPrevious value: -"Named loss functions as ArithmeticExpr over primitives, with optional upper bounds."New value: +"Loss functions as ArithmeticExpr with optional upper bounds."Input schema / properties / claim / properties / operators / descriptionPrevious value: -"Declared operators with name, arity, input primitive names, output primitive name, and totality flag."New value: +"Operators with name, arity, input/output primitive names, totality flag."Input schema / properties / claim / properties / policy / descriptionPrevious value: -"PolicyConfig overrides: hash_alg, solver_backend, timeouts, thresholds. Defaults to VERITAS Omega v1.3.1 canonical values if omitted."New value: +"PolicyConfig overrides for hash_alg, solver_backend, timeouts, thresholds."Input schema / properties / claim / properties / primitives / descriptionPrevious value: -"Declared typed variables with name, domain (Interval/EnumSet/FiniteSet), optional units, and description."New value: +"Typed variables with name, domain (Interval/EnumSet/FiniteSet), optional units."Input schema / properties / claim / properties / project / descriptionPrevious value: -"Unique project identifier, e.g. 'omega-brain-mcp'."New value: +"Project identifier, e.g. 'omega-brain-mcp'."Input schema / properties / claim / properties / regimes / descriptionPrevious value: -"Named operating regimes, each with a predicate ConstraintExpr over declared primitives."New value: +"Operating regimes with name and predicate ConstraintExpr."Input schema / properties / claim / properties / security / descriptionPrevious value: -"Security posture declaration: SAST results, secret scan findings, injection surfaces, auth boundaries, and TLS/crypto configuration."New value: +"Security posture: SAST results, secret scan, injection surfaces, auth, TLS config."Input schema / properties / claim / properties / version / descriptionPrevious value: -"Semantic version string of the build being evaluated, e.g. '2.1.0'."New value: +"Semantic version, e.g. '2.1.0'."Input schema / properties / fail_fast / descriptionPrevious value: -"When true (default), halt the pipeline on the first VIOLATION verdict and skip remaining gates. Set to false to run all gates and collect every verdict."New value: +"If true (default), halts on first VIOLATION. Set false to collect all gate verdicts."veritas_security_gate16 fields changedInput schema / properties / claim / descriptionPrevious value: -"A VERITAS BuildClaim object containing all declared primitives, operators, regimes, boundaries, loss models, evidence items, cost vectors, and policy configuration needed for deterministic gate evaluation. All fields are optional for partial evaluation — only the fields relevant to the gate being invoked are required."New value: +"A VERITAS BuildClaim object for deterministic gate evaluation. All fields are optional for partial evaluation — only fields relevant to the invoked gate are required."Input schema / properties / claim / properties / attack_suite / descriptionPrevious value: -"AttackSuite with suite_id and list of Attack transforms (InflateBound, RemoveEvidence, PerturbParam, PerturbEvidence) for adversary gate."New value: +"Attack transforms for adversary testing: InflateBound, RemoveEvidence, PerturbParam, PerturbEvidence."Input schema / properties / claim / properties / boundaries / descriptionPrevious value: -"Named boundary constraints (e.g. 'CAPEX_USD <= 100000') that the claim must satisfy."New value: +"Boundary constraints, e.g. {name: 'cap', constraint: 'CAPEX_USD <= 100000'}."Input schema / properties / claim / properties / commit / descriptionPrevious value: -"Git commit SHA for reproducibility and audit trail."New value: +"Git commit SHA for reproducibility."Input schema / properties / claim / properties / cost / descriptionPrevious value: -"CostVector with optional fields: compute_flops, memory_bytes, wall_clock_s, capital_usd, coordination_agents."New value: +"CostVector: compute_flops, memory_bytes, wall_clock_s, capital_usd, coordination_agents."Input schema / properties / claim / properties / cost_bounds / descriptionPrevious value: -"Upper bounds for each cost component. Utilization = max(cost_i / bound_i). Values must be > 0."New value: +"Upper bounds for each cost component. All values must be > 0."Input schema / properties / claim / properties / dependencies / descriptionPrevious value: -"SBOM-style dependency manifest for supply-chain analysis: package names, versions, registries, and integrity hashes."New value: +"SBOM-style dependency manifest: package names, versions, registries, hashes."Input schema / properties / claim / properties / evidence / descriptionPrevious value: -"Evidence items, each with id, variable, value (Numeric or Categorical), timestamp, method, provenance, and optional dependencies."New value: +"Evidence items with id, variable, value, timestamp, method, provenance."Input schema / properties / claim / properties / loss_models / descriptionPrevious value: -"Named loss functions as ArithmeticExpr over primitives, with optional upper bounds."New value: +"Loss functions as ArithmeticExpr with optional upper bounds."Input schema / properties / claim / properties / operators / descriptionPrevious value: -"Declared operators with name, arity, input primitive names, output primitive name, and totality flag."New value: +"Operators with name, arity, input/output primitive names, totality flag."Input schema / properties / claim / properties / policy / descriptionPrevious value: -"PolicyConfig overrides: hash_alg, solver_backend, timeouts, thresholds. Defaults to VERITAS Omega v1.3.1 canonical values if omitted."New value: +"PolicyConfig overrides for hash_alg, solver_backend, timeouts, thresholds."Input schema / properties / claim / properties / primitives / descriptionPrevious value: -"Declared typed variables with name, domain (Interval/EnumSet/FiniteSet), optional units, and description."New value: +"Typed variables with name, domain (Interval/EnumSet/FiniteSet), optional units."Input schema / properties / claim / properties / project / descriptionPrevious value: -"Unique project identifier, e.g. 'omega-brain-mcp'."New value: +"Project identifier, e.g. 'omega-brain-mcp'."Input schema / properties / claim / properties / regimes / descriptionPrevious value: -"Named operating regimes, each with a predicate ConstraintExpr over declared primitives."New value: +"Operating regimes with name and predicate ConstraintExpr."Input schema / properties / claim / properties / security / descriptionPrevious value: -"Security posture declaration: SAST results, secret scan findings, injection surfaces, auth boundaries, and TLS/crypto configuration."New value: +"Security posture: SAST results, secret scan, injection surfaces, auth, TLS config."Input schema / properties / claim / properties / version / descriptionPrevious value: -"Semantic version string of the build being evaluated, e.g. '2.1.0'."New value: +"Semantic version, e.g. '2.1.0'."veritas_type_gate16 fields changedInput schema / properties / claim / descriptionPrevious value: -"A VERITAS BuildClaim object containing all declared primitives, operators, regimes, boundaries, loss models, evidence items, cost vectors, and policy configuration needed for deterministic gate evaluation. All fields are optional for partial evaluation — only the fields relevant to the gate being invoked are required."New value: +"A VERITAS BuildClaim object for deterministic gate evaluation. All fields are optional for partial evaluation — only fields relevant to the invoked gate are required."Input schema / properties / claim / properties / attack_suite / descriptionPrevious value: -"AttackSuite with suite_id and list of Attack transforms (InflateBound, RemoveEvidence, PerturbParam, PerturbEvidence) for adversary gate."New value: +"Attack transforms for adversary testing: InflateBound, RemoveEvidence, PerturbParam, PerturbEvidence."Input schema / properties / claim / properties / boundaries / descriptionPrevious value: -"Named boundary constraints (e.g. 'CAPEX_USD <= 100000') that the claim must satisfy."New value: +"Boundary constraints, e.g. {name: 'cap', constraint: 'CAPEX_USD <= 100000'}."Input schema / properties / claim / properties / commit / descriptionPrevious value: -"Git commit SHA for reproducibility and audit trail."New value: +"Git commit SHA for reproducibility."Input schema / properties / claim / properties / cost / descriptionPrevious value: -"CostVector with optional fields: compute_flops, memory_bytes, wall_clock_s, capital_usd, coordination_agents."New value: +"CostVector: compute_flops, memory_bytes, wall_clock_s, capital_usd, coordination_agents."Input schema / properties / claim / properties / cost_bounds / descriptionPrevious value: -"Upper bounds for each cost component. Utilization = max(cost_i / bound_i). Values must be > 0."New value: +"Upper bounds for each cost component. All values must be > 0."Input schema / properties / claim / properties / dependencies / descriptionPrevious value: -"SBOM-style dependency manifest for supply-chain analysis: package names, versions, registries, and integrity hashes."New value: +"SBOM-style dependency manifest: package names, versions, registries, hashes."Input schema / properties / claim / properties / evidence / descriptionPrevious value: -"Evidence items, each with id, variable, value (Numeric or Categorical), timestamp, method, provenance, and optional dependencies."New value: +"Evidence items with id, variable, value, timestamp, method, provenance."Input schema / properties / claim / properties / loss_models / descriptionPrevious value: -"Named loss functions as ArithmeticExpr over primitives, with optional upper bounds."New value: +"Loss functions as ArithmeticExpr with optional upper bounds."Input schema / properties / claim / properties / operators / descriptionPrevious value: -"Declared operators with name, arity, input primitive names, output primitive name, and totality flag."New value: +"Operators with name, arity, input/output primitive names, totality flag."Input schema / properties / claim / properties / policy / descriptionPrevious value: -"PolicyConfig overrides: hash_alg, solver_backend, timeouts, thresholds. Defaults to VERITAS Omega v1.3.1 canonical values if omitted."New value: +"PolicyConfig overrides for hash_alg, solver_backend, timeouts, thresholds."Input schema / properties / claim / properties / primitives / descriptionPrevious value: -"Declared typed variables with name, domain (Interval/EnumSet/FiniteSet), optional units, and description."New value: +"Typed variables with name, domain (Interval/EnumSet/FiniteSet), optional units."Input schema / properties / claim / properties / project / descriptionPrevious value: -"Unique project identifier, e.g. 'omega-brain-mcp'."New value: +"Project identifier, e.g. 'omega-brain-mcp'."Input schema / properties / claim / properties / regimes / descriptionPrevious value: -"Named operating regimes, each with a predicate ConstraintExpr over declared primitives."New value: +"Operating regimes with name and predicate ConstraintExpr."Input schema / properties / claim / properties / security / descriptionPrevious value: -"Security posture declaration: SAST results, secret scan findings, injection surfaces, auth boundaries, and TLS/crypto configuration."New value: +"Security posture: SAST results, secret scan, injection surfaces, auth, TLS config."Input schema / properties / claim / properties / version / descriptionPrevious value: -"Semantic version string of the build being evaluated, e.g. '2.1.0'."New value: +"Semantic version, e.g. '2.1.0'."v1.0.1omega_brain_report1 field changedInput schema / properties / lines / descriptionPrevious value: -"Ledger entries to show (default 10)"New value: +"Number of recent SEAL ledger entries to include in the report. Higher values show more audit history."omega_cortex_check3 fields changedInput schema / properties / args / descriptionAdded value: +"The arguments that will be passed to the tool. These are serialized and compared against the baseline for drift detection."Input schema / properties / baseline_prompt / descriptionAdded value: +"The declared task baseline describing the intended operation. The Cortex measures semantic distance between this baseline and the tool+args to detect drift."Input schema / properties / tool / descriptionAdded value: +"The name of the tool being checked for alignment, e.g. 'omega_ingest' or 'veritas_run_pipeline'."omega_cortex_steer3 fields changedInput schema / properties / args / descriptionAdded value: +"The original tool arguments that may be drifting from the baseline. These will be corrected if within steering range."Input schema / properties / baseline_prompt / descriptionAdded value: +"The task baseline that defines the intended direction. Arguments are steered toward alignment with this baseline."Input schema / properties / tool / descriptionAdded value: +"The name of the tool whose arguments need steering, e.g. 'omega_ingest' or 'omega_seal_run'."omega_execute3 fields changedInput schema / properties / args / descriptionPrevious value: -"Tool arguments"New value: +"The arguments to pass to the target tool. These may be steered by the Cortex if they drift from the baseline."Input schema / properties / baseline / descriptionPrevious value: -"Task baseline for cortex check"New value: +"Task baseline description for the Cortex alignment check. The Cortex measures semantic distance between this baseline and the tool+args."Input schema / properties / tool / descriptionPrevious value: -"Omega Brain tool to execute"New value: +"The name of the Omega Brain tool to execute, e.g. 'omega_ingest', 'omega_rag_query', 'omega_seal_run'. Only Omega Brain tools can be dispatched through this wrapper."omega_ingest4 fields changedInput schema / properties / content / descriptionPrevious value: -"Text to ingest"New value: +"The text content to ingest into the RAG store. Can be any knowledge fragment: a decision rationale, code pattern, finding, or reference material."Input schema / properties / source / descriptionPrevious value: -"Source identifier"New value: +"Identifier for the origin of this knowledge, e.g. 'user-session', 'code-review', 'documentation'. Used for provenance tracking and dominance analysis."Input schema / properties / tier / descriptionPrevious value: -"Evidence tier: A/B/C/D"New value: +"VERITAS evidence tier rating. A = highest confidence (verified, reproducible), B = high (reliable source), C = moderate (single source), D = low (unverified). Affects Quality(e) scoring."Input schema / properties / tier / enumAdded value: +[
+ "A",
+ "B",
+ "C",
+ "D"
+]omega_log_session4 fields changedInput schema / properties / decisions / descriptionAdded value: +"List of key decisions made during the session, e.g. ['Used setuptools over poetry', 'Pinned dependency to v3.2.1']."Input schema / properties / files_modified / descriptionAdded value: +"List of file paths that were created or modified during the session, e.g. ['src/main.py', 'pyproject.toml']."Input schema / properties / session_id / descriptionAdded value: +"Optional unique identifier for this session. If omitted, the current server session ID is used."Input schema / properties / task / descriptionAdded value: +"Natural-language description of the task completed during this session."omega_preload_context1 field changedInput schema / properties / task / descriptionPrevious value: -"What are you working on?"New value: +"A natural-language description of the task you are starting. This is used to query the RAG store for relevant prior knowledge and to classify context continuity."omega_rag_query2 fields changedInput schema / properties / query / descriptionAdded value: +"Natural-language search query to match against stored knowledge fragments using semantic similarity."Input schema / properties / top_k / descriptionAdded value: +"Maximum number of ranked results to return. Higher values return more matches but may include lower-relevance fragments."omega_seal_run2 fields changedInput schema / properties / context / descriptionAdded value: +"Structured metadata for the seal entry. Should contain key-value pairs describing the event being recorded, e.g. {'action': 'deploy', 'target': 'production', 'version': '2.1.0'}."Input schema / properties / response / descriptionAdded value: +"The response or outcome text to seal into the audit ledger. This becomes part of the immutable hash chain."omega_vault_search1 field changedInput schema / properties / query / descriptionAdded value: +"Keyword search query for full-text search. Supports SQLite FTS5 syntax: AND, OR, NOT, phrase matching with double quotes."omega_write_handoff6 fields changedInput schema / properties / conversation_id / descriptionAdded value: +"Optional conversation identifier for cross-referencing with external conversation tracking systems."Input schema / properties / decisions / descriptionAdded value: +"Key architectural or implementation decisions that the next session should be aware of."Input schema / properties / files_modified / descriptionAdded value: +"Files that were changed during this session, so the next session knows what to review."Input schema / properties / next_steps / descriptionAdded value: +"Ordered list of recommended next actions for the continuation session."Input schema / properties / summary / descriptionAdded value: +"Concise summary of what was accomplished and the current state. This is the primary context the next session will receive."Input schema / properties / task / descriptionAdded value: +"The task that was being worked on, used as the handoff title."veritas_adversary_gate16 fields changedInput schema / properties / claim / descriptionPrevious value: -"Full or partial VERITAS BuildClaim object"New value: +"A VERITAS BuildClaim object containing all declared primitives, operators, regimes, boundaries, loss models, evidence items, cost vectors, and policy configuration needed for deterministic gate evaluation. All fields are optional for partial evaluation — only the fields relevant to the gate being invoked are required."Input schema / properties / claim / properties / attack_suite / descriptionAdded value: +"AttackSuite with suite_id and list of Attack transforms (InflateBound, RemoveEvidence, PerturbParam, PerturbEvidence) for adversary gate."Input schema / properties / claim / properties / boundaries / descriptionAdded value: +"Named boundary constraints (e.g. 'CAPEX_USD <= 100000') that the claim must satisfy."Input schema / properties / claim / properties / commit / descriptionAdded value: +"Git commit SHA for reproducibility and audit trail."Input schema / properties / claim / properties / cost / descriptionAdded value: +"CostVector with optional fields: compute_flops, memory_bytes, wall_clock_s, capital_usd, coordination_agents."Input schema / properties / claim / properties / cost_bounds / descriptionAdded value: +"Upper bounds for each cost component. Utilization = max(cost_i / bound_i). Values must be > 0."Input schema / properties / claim / properties / dependencies / descriptionAdded value: +"SBOM-style dependency manifest for supply-chain analysis: package names, versions, registries, and integrity hashes."Input schema / properties / claim / properties / evidence / descriptionAdded value: +"Evidence items, each with id, variable, value (Numeric or Categorical), timestamp, method, provenance, and optional dependencies."Input schema / properties / claim / properties / loss_models / descriptionAdded value: +"Named loss functions as ArithmeticExpr over primitives, with optional upper bounds."Input schema / properties / claim / properties / operators / descriptionAdded value: +"Declared operators with name, arity, input primitive names, output primitive name, and totality flag."Input schema / properties / claim / properties / policy / descriptionAdded value: +"PolicyConfig overrides: hash_alg, solver_backend, timeouts, thresholds. Defaults to VERITAS Omega v1.3.1 canonical values if omitted."Input schema / properties / claim / properties / primitives / descriptionAdded value: +"Declared typed variables with name, domain (Interval/EnumSet/FiniteSet), optional units, and description."Input schema / properties / claim / properties / project / descriptionAdded value: +"Unique project identifier, e.g. 'omega-brain-mcp'."Input schema / properties / claim / properties / regimes / descriptionAdded value: +"Named operating regimes, each with a predicate ConstraintExpr over declared primitives."Input schema / properties / claim / properties / security / descriptionAdded value: +"Security posture declaration: SAST results, secret scan findings, injection surfaces, auth boundaries, and TLS/crypto configuration."Input schema / properties / claim / properties / version / descriptionAdded value: +"Semantic version string of the build being evaluated, e.g. '2.1.0'."veritas_claeg_resolve1 field changedInput schema / properties / verdict / descriptionAdded value: +"The VERITAS verdict to resolve into a CLAEG terminal state. Must be one of the four canonical verdict values."veritas_claeg_transition2 fields changedInput schema / properties / current_state / descriptionAdded value: +"The current CLAEG state of the system, e.g. 'STABLE_CONTINUATION', 'ISOLATED_CONTAINMENT', or 'TERMINAL_SHUTDOWN'."Input schema / properties / target_state / descriptionAdded value: +"The desired target CLAEG state to transition to. The validator checks if this transition is permitted."veritas_compute_quality2 fields changedInput schema / properties / evidence_item / descriptionPrevious value: -"Single evidence item with provenance, method, timestamp, ttl_seconds"New value: +"A single VERITAS evidence item containing at minimum: provenance (with tier and source_id), method (with protocol and repeatable flag), value (with x, units, and optional uncertainty), and timestamp."Input schema / properties / policy_env / descriptionPrevious value: -"Policy environment spec for match scoring"New value: +"Optional policy environment specification for environment-match scoring. Defaults to empty object if omitted."veritas_cost_gate16 fields changedInput schema / properties / claim / descriptionPrevious value: -"Full or partial VERITAS BuildClaim object"New value: +"A VERITAS BuildClaim object containing all declared primitives, operators, regimes, boundaries, loss models, evidence items, cost vectors, and policy configuration needed for deterministic gate evaluation. All fields are optional for partial evaluation — only the fields relevant to the gate being invoked are required."Input schema / properties / claim / properties / attack_suite / descriptionAdded value: +"AttackSuite with suite_id and list of Attack transforms (InflateBound, RemoveEvidence, PerturbParam, PerturbEvidence) for adversary gate."Input schema / properties / claim / properties / boundaries / descriptionAdded value: +"Named boundary constraints (e.g. 'CAPEX_USD <= 100000') that the claim must satisfy."Input schema / properties / claim / properties / commit / descriptionAdded value: +"Git commit SHA for reproducibility and audit trail."Input schema / properties / claim / properties / cost / descriptionAdded value: +"CostVector with optional fields: compute_flops, memory_bytes, wall_clock_s, capital_usd, coordination_agents."Input schema / properties / claim / properties / cost_bounds / descriptionAdded value: +"Upper bounds for each cost component. Utilization = max(cost_i / bound_i). Values must be > 0."Input schema / properties / claim / properties / dependencies / descriptionAdded value: +"SBOM-style dependency manifest for supply-chain analysis: package names, versions, registries, and integrity hashes."Input schema / properties / claim / properties / evidence / descriptionAdded value: +"Evidence items, each with id, variable, value (Numeric or Categorical), timestamp, method, provenance, and optional dependencies."Input schema / properties / claim / properties / loss_models / descriptionAdded value: +"Named loss functions as ArithmeticExpr over primitives, with optional upper bounds."Input schema / properties / claim / properties / operators / descriptionAdded value: +"Declared operators with name, arity, input primitive names, output primitive name, and totality flag."Input schema / properties / claim / properties / policy / descriptionAdded value: +"PolicyConfig overrides: hash_alg, solver_backend, timeouts, thresholds. Defaults to VERITAS Omega v1.3.1 canonical values if omitted."Input schema / properties / claim / properties / primitives / descriptionAdded value: +"Declared typed variables with name, domain (Interval/EnumSet/FiniteSet), optional units, and description."Input schema / properties / claim / properties / project / descriptionAdded value: +"Unique project identifier, e.g. 'omega-brain-mcp'."Input schema / properties / claim / properties / regimes / descriptionAdded value: +"Named operating regimes, each with a predicate ConstraintExpr over declared primitives."Input schema / properties / claim / properties / security / descriptionAdded value: +"Security posture declaration: SAST results, secret scan findings, injection surfaces, auth boundaries, and TLS/crypto configuration."Input schema / properties / claim / properties / version / descriptionAdded value: +"Semantic version string of the build being evaluated, e.g. '2.1.0'."veritas_dependency_gate16 fields changedInput schema / properties / claim / descriptionPrevious value: -"Full or partial VERITAS BuildClaim object"New value: +"A VERITAS BuildClaim object containing all declared primitives, operators, regimes, boundaries, loss models, evidence items, cost vectors, and policy configuration needed for deterministic gate evaluation. All fields are optional for partial evaluation — only the fields relevant to the gate being invoked are required."Input schema / properties / claim / properties / attack_suite / descriptionAdded value: +"AttackSuite with suite_id and list of Attack transforms (InflateBound, RemoveEvidence, PerturbParam, PerturbEvidence) for adversary gate."Input schema / properties / claim / properties / boundaries / descriptionAdded value: +"Named boundary constraints (e.g. 'CAPEX_USD <= 100000') that the claim must satisfy."Input schema / properties / claim / properties / commit / descriptionAdded value: +"Git commit SHA for reproducibility and audit trail."Input schema / properties / claim / properties / cost / descriptionAdded value: +"CostVector with optional fields: compute_flops, memory_bytes, wall_clock_s, capital_usd, coordination_agents."Input schema / properties / claim / properties / cost_bounds / descriptionAdded value: +"Upper bounds for each cost component. Utilization = max(cost_i / bound_i). Values must be > 0."Input schema / properties / claim / properties / dependencies / descriptionAdded value: +"SBOM-style dependency manifest for supply-chain analysis: package names, versions, registries, and integrity hashes."Input schema / properties / claim / properties / evidence / descriptionAdded value: +"Evidence items, each with id, variable, value (Numeric or Categorical), timestamp, method, provenance, and optional dependencies."Input schema / properties / claim / properties / loss_models / descriptionAdded value: +"Named loss functions as ArithmeticExpr over primitives, with optional upper bounds."Input schema / properties / claim / properties / operators / descriptionAdded value: +"Declared operators with name, arity, input primitive names, output primitive name, and totality flag."Input schema / properties / claim / properties / policy / descriptionAdded value: +"PolicyConfig overrides: hash_alg, solver_backend, timeouts, thresholds. Defaults to VERITAS Omega v1.3.1 canonical values if omitted."Input schema / properties / claim / properties / primitives / descriptionAdded value: +"Declared typed variables with name, domain (Interval/EnumSet/FiniteSet), optional units, and description."Input schema / properties / claim / properties / project / descriptionAdded value: +"Unique project identifier, e.g. 'omega-brain-mcp'."Input schema / properties / claim / properties / regimes / descriptionAdded value: +"Named operating regimes, each with a predicate ConstraintExpr over declared primitives."Input schema / properties / claim / properties / security / descriptionAdded value: +"Security posture declaration: SAST results, secret scan findings, injection surfaces, auth boundaries, and TLS/crypto configuration."Input schema / properties / claim / properties / version / descriptionAdded value: +"Semantic version string of the build being evaluated, e.g. '2.1.0'."veritas_evidence_gate18 fields changedInput schema / properties / claim / descriptionPrevious value: -"Full or partial VERITAS BuildClaim object"New value: +"A VERITAS BuildClaim object containing all declared primitives, operators, regimes, boundaries, loss models, evidence items, cost vectors, and policy configuration needed for deterministic gate evaluation. All fields are optional for partial evaluation — only the fields relevant to the gate being invoked are required."Input schema / properties / claim / properties / attack_suite / descriptionAdded value: +"AttackSuite with suite_id and list of Attack transforms (InflateBound, RemoveEvidence, PerturbParam, PerturbEvidence) for adversary gate."Input schema / properties / claim / properties / boundaries / descriptionAdded value: +"Named boundary constraints (e.g. 'CAPEX_USD <= 100000') that the claim must satisfy."Input schema / properties / claim / properties / commit / descriptionAdded value: +"Git commit SHA for reproducibility and audit trail."Input schema / properties / claim / properties / cost / descriptionAdded value: +"CostVector with optional fields: compute_flops, memory_bytes, wall_clock_s, capital_usd, coordination_agents."Input schema / properties / claim / properties / cost_bounds / descriptionAdded value: +"Upper bounds for each cost component. Utilization = max(cost_i / bound_i). Values must be > 0."Input schema / properties / claim / properties / dependencies / descriptionAdded value: +"SBOM-style dependency manifest for supply-chain analysis: package names, versions, registries, and integrity hashes."Input schema / properties / claim / properties / evidence / descriptionAdded value: +"Evidence items, each with id, variable, value (Numeric or Categorical), timestamp, method, provenance, and optional dependencies."Input schema / properties / claim / properties / loss_models / descriptionAdded value: +"Named loss functions as ArithmeticExpr over primitives, with optional upper bounds."Input schema / properties / claim / properties / operators / descriptionAdded value: +"Declared operators with name, arity, input primitive names, output primitive name, and totality flag."Input schema / properties / claim / properties / policy / descriptionAdded value: +"PolicyConfig overrides: hash_alg, solver_backend, timeouts, thresholds. Defaults to VERITAS Omega v1.3.1 canonical values if omitted."Input schema / properties / claim / properties / primitives / descriptionAdded value: +"Declared typed variables with name, domain (Interval/EnumSet/FiniteSet), optional units, and description."Input schema / properties / claim / properties / project / descriptionAdded value: +"Unique project identifier, e.g. 'omega-brain-mcp'."Input schema / properties / claim / properties / regimes / descriptionAdded value: +"Named operating regimes, each with a predicate ConstraintExpr over declared primitives."Input schema / properties / claim / properties / security / descriptionAdded value: +"Security posture declaration: SAST results, secret scan findings, injection surfaces, auth boundaries, and TLS/crypto configuration."Input schema / properties / claim / properties / version / descriptionAdded value: +"Semantic version string of the build being evaluated, e.g. '2.1.0'."Input schema / properties / regime / descriptionPrevious value: -"Build regime: dev|staging|production"New value: +"Build regime that determines evidence threshold strictness. 'dev' uses baseline thresholds (K=2, A=0.80, Q=0.70), 'production' uses escalated irreversibility thresholds (K=3, A=0.90, Q=0.80)."Input schema / properties / regime / enumAdded value: +[
+ "dev",
+ "staging",
+ "production"
+]veritas_incentive_gate16 fields changedInput schema / properties / claim / descriptionPrevious value: -"Full or partial VERITAS BuildClaim object"New value: +"A VERITAS BuildClaim object containing all declared primitives, operators, regimes, boundaries, loss models, evidence items, cost vectors, and policy configuration needed for deterministic gate evaluation. All fields are optional for partial evaluation — only the fields relevant to the gate being invoked are required."Input schema / properties / claim / properties / attack_suite / descriptionAdded value: +"AttackSuite with suite_id and list of Attack transforms (InflateBound, RemoveEvidence, PerturbParam, PerturbEvidence) for adversary gate."Input schema / properties / claim / properties / boundaries / descriptionAdded value: +"Named boundary constraints (e.g. 'CAPEX_USD <= 100000') that the claim must satisfy."Input schema / properties / claim / properties / commit / descriptionAdded value: +"Git commit SHA for reproducibility and audit trail."Input schema / properties / claim / properties / cost / descriptionAdded value: +"CostVector with optional fields: compute_flops, memory_bytes, wall_clock_s, capital_usd, coordination_agents."Input schema / properties / claim / properties / cost_bounds / descriptionAdded value: +"Upper bounds for each cost component. Utilization = max(cost_i / bound_i). Values must be > 0."Input schema / properties / claim / properties / dependencies / descriptionAdded value: +"SBOM-style dependency manifest for supply-chain analysis: package names, versions, registries, and integrity hashes."Input schema / properties / claim / properties / evidence / descriptionAdded value: +"Evidence items, each with id, variable, value (Numeric or Categorical), timestamp, method, provenance, and optional dependencies."Input schema / properties / claim / properties / loss_models / descriptionAdded value: +"Named loss functions as ArithmeticExpr over primitives, with optional upper bounds."Input schema / properties / claim / properties / operators / descriptionAdded value: +"Declared operators with name, arity, input primitive names, output primitive name, and totality flag."Input schema / properties / claim / properties / policy / descriptionAdded value: +"PolicyConfig overrides: hash_alg, solver_backend, timeouts, thresholds. Defaults to VERITAS Omega v1.3.1 canonical values if omitted."Input schema / properties / claim / properties / primitives / descriptionAdded value: +"Declared typed variables with name, domain (Interval/EnumSet/FiniteSet), optional units, and description."Input schema / properties / claim / properties / project / descriptionAdded value: +"Unique project identifier, e.g. 'omega-brain-mcp'."Input schema / properties / claim / properties / regimes / descriptionAdded value: +"Named operating regimes, each with a predicate ConstraintExpr over declared primitives."Input schema / properties / claim / properties / security / descriptionAdded value: +"Security posture declaration: SAST results, secret scan findings, injection surfaces, auth boundaries, and TLS/crypto configuration."Input schema / properties / claim / properties / version / descriptionAdded value: +"Semantic version string of the build being evaluated, e.g. '2.1.0'."veritas_intake_gate16 fields changedInput schema / properties / claim / descriptionPrevious value: -"Full or partial VERITAS BuildClaim object"New value: +"A VERITAS BuildClaim object containing all declared primitives, operators, regimes, boundaries, loss models, evidence items, cost vectors, and policy configuration needed for deterministic gate evaluation. All fields are optional for partial evaluation — only the fields relevant to the gate being invoked are required."Input schema / properties / claim / properties / attack_suite / descriptionAdded value: +"AttackSuite with suite_id and list of Attack transforms (InflateBound, RemoveEvidence, PerturbParam, PerturbEvidence) for adversary gate."Input schema / properties / claim / properties / boundaries / descriptionAdded value: +"Named boundary constraints (e.g. 'CAPEX_USD <= 100000') that the claim must satisfy."Input schema / properties / claim / properties / commit / descriptionAdded value: +"Git commit SHA for reproducibility and audit trail."Input schema / properties / claim / properties / cost / descriptionAdded value: +"CostVector with optional fields: compute_flops, memory_bytes, wall_clock_s, capital_usd, coordination_agents."Input schema / properties / claim / properties / cost_bounds / descriptionAdded value: +"Upper bounds for each cost component. Utilization = max(cost_i / bound_i). Values must be > 0."Input schema / properties / claim / properties / dependencies / descriptionAdded value: +"SBOM-style dependency manifest for supply-chain analysis: package names, versions, registries, and integrity hashes."Input schema / properties / claim / properties / evidence / descriptionAdded value: +"Evidence items, each with id, variable, value (Numeric or Categorical), timestamp, method, provenance, and optional dependencies."Input schema / properties / claim / properties / loss_models / descriptionAdded value: +"Named loss functions as ArithmeticExpr over primitives, with optional upper bounds."Input schema / properties / claim / properties / operators / descriptionAdded value: +"Declared operators with name, arity, input primitive names, output primitive name, and totality flag."Input schema / properties / claim / properties / policy / descriptionAdded value: +"PolicyConfig overrides: hash_alg, solver_backend, timeouts, thresholds. Defaults to VERITAS Omega v1.3.1 canonical values if omitted."Input schema / properties / claim / properties / primitives / descriptionAdded value: +"Declared typed variables with name, domain (Interval/EnumSet/FiniteSet), optional units, and description."Input schema / properties / claim / properties / project / descriptionAdded value: +"Unique project identifier, e.g. 'omega-brain-mcp'."Input schema / properties / claim / properties / regimes / descriptionAdded value: +"Named operating regimes, each with a predicate ConstraintExpr over declared primitives."Input schema / properties / claim / properties / security / descriptionAdded value: +"Security posture declaration: SAST results, secret scan findings, injection surfaces, auth boundaries, and TLS/crypto configuration."Input schema / properties / claim / properties / version / descriptionAdded value: +"Semantic version string of the build being evaluated, e.g. '2.1.0'."veritas_math_gate16 fields changedInput schema / properties / claim / descriptionPrevious value: -"Full or partial VERITAS BuildClaim object"New value: +"A VERITAS BuildClaim object containing all declared primitives, operators, regimes, boundaries, loss models, evidence items, cost vectors, and policy configuration needed for deterministic gate evaluation. All fields are optional for partial evaluation — only the fields relevant to the gate being invoked are required."Input schema / properties / claim / properties / attack_suite / descriptionAdded value: +"AttackSuite with suite_id and list of Attack transforms (InflateBound, RemoveEvidence, PerturbParam, PerturbEvidence) for adversary gate."Input schema / properties / claim / properties / boundaries / descriptionAdded value: +"Named boundary constraints (e.g. 'CAPEX_USD <= 100000') that the claim must satisfy."Input schema / properties / claim / properties / commit / descriptionAdded value: +"Git commit SHA for reproducibility and audit trail."Input schema / properties / claim / properties / cost / descriptionAdded value: +"CostVector with optional fields: compute_flops, memory_bytes, wall_clock_s, capital_usd, coordination_agents."Input schema / properties / claim / properties / cost_bounds / descriptionAdded value: +"Upper bounds for each cost component. Utilization = max(cost_i / bound_i). Values must be > 0."Input schema / properties / claim / properties / dependencies / descriptionAdded value: +"SBOM-style dependency manifest for supply-chain analysis: package names, versions, registries, and integrity hashes."Input schema / properties / claim / properties / evidence / descriptionAdded value: +"Evidence items, each with id, variable, value (Numeric or Categorical), timestamp, method, provenance, and optional dependencies."Input schema / properties / claim / properties / loss_models / descriptionAdded value: +"Named loss functions as ArithmeticExpr over primitives, with optional upper bounds."Input schema / properties / claim / properties / operators / descriptionAdded value: +"Declared operators with name, arity, input primitive names, output primitive name, and totality flag."Input schema / properties / claim / properties / policy / descriptionAdded value: +"PolicyConfig overrides: hash_alg, solver_backend, timeouts, thresholds. Defaults to VERITAS Omega v1.3.1 canonical values if omitted."Input schema / properties / claim / properties / primitives / descriptionAdded value: +"Declared typed variables with name, domain (Interval/EnumSet/FiniteSet), optional units, and description."Input schema / properties / claim / properties / project / descriptionAdded value: +"Unique project identifier, e.g. 'omega-brain-mcp'."Input schema / properties / claim / properties / regimes / descriptionAdded value: +"Named operating regimes, each with a predicate ConstraintExpr over declared primitives."Input schema / properties / claim / properties / security / descriptionAdded value: +"Security posture declaration: SAST results, secret scan findings, injection surfaces, auth boundaries, and TLS/crypto configuration."Input schema / properties / claim / properties / version / descriptionAdded value: +"Semantic version string of the build being evaluated, e.g. '2.1.0'."veritas_mis_greedy1 field changedInput schema / properties / evidence_items / descriptionPrevious value: -"Evidence items to find independent set from"New value: +"Array of VERITAS evidence items to analyze for independence. Each item should have id, variable, value, timestamp, method, provenance, and optional dependencies."veritas_nafe_scan1 field changedInput schema / properties / text / descriptionPrevious value: -"Text to scan for NAFE failure signatures"New value: +"The text content to scan for NAFE failure signatures. Can be a commit message, PR description, incident report, or any narrative text that might attempt to bypass deterministic gate verdicts."veritas_run_pipeline17 fields changedInput schema / properties / claim / descriptionPrevious value: -"Full or partial VERITAS BuildClaim object"New value: +"A VERITAS BuildClaim object containing all declared primitives, operators, regimes, boundaries, loss models, evidence items, cost vectors, and policy configuration needed for deterministic gate evaluation. All fields are optional for partial evaluation — only the fields relevant to the gate being invoked are required."Input schema / properties / claim / properties / attack_suite / descriptionAdded value: +"AttackSuite with suite_id and list of Attack transforms (InflateBound, RemoveEvidence, PerturbParam, PerturbEvidence) for adversary gate."Input schema / properties / claim / properties / boundaries / descriptionAdded value: +"Named boundary constraints (e.g. 'CAPEX_USD <= 100000') that the claim must satisfy."Input schema / properties / claim / properties / commit / descriptionAdded value: +"Git commit SHA for reproducibility and audit trail."Input schema / properties / claim / properties / cost / descriptionAdded value: +"CostVector with optional fields: compute_flops, memory_bytes, wall_clock_s, capital_usd, coordination_agents."Input schema / properties / claim / properties / cost_bounds / descriptionAdded value: +"Upper bounds for each cost component. Utilization = max(cost_i / bound_i). Values must be > 0."Input schema / properties / claim / properties / dependencies / descriptionAdded value: +"SBOM-style dependency manifest for supply-chain analysis: package names, versions, registries, and integrity hashes."Input schema / properties / claim / properties / evidence / descriptionAdded value: +"Evidence items, each with id, variable, value (Numeric or Categorical), timestamp, method, provenance, and optional dependencies."Input schema / properties / claim / properties / loss_models / descriptionAdded value: +"Named loss functions as ArithmeticExpr over primitives, with optional upper bounds."Input schema / properties / claim / properties / operators / descriptionAdded value: +"Declared operators with name, arity, input primitive names, output primitive name, and totality flag."Input schema / properties / claim / properties / policy / descriptionAdded value: +"PolicyConfig overrides: hash_alg, solver_backend, timeouts, thresholds. Defaults to VERITAS Omega v1.3.1 canonical values if omitted."Input schema / properties / claim / properties / primitives / descriptionAdded value: +"Declared typed variables with name, domain (Interval/EnumSet/FiniteSet), optional units, and description."Input schema / properties / claim / properties / project / descriptionAdded value: +"Unique project identifier, e.g. 'omega-brain-mcp'."Input schema / properties / claim / properties / regimes / descriptionAdded value: +"Named operating regimes, each with a predicate ConstraintExpr over declared primitives."Input schema / properties / claim / properties / security / descriptionAdded value: +"Security posture declaration: SAST results, secret scan findings, injection surfaces, auth boundaries, and TLS/crypto configuration."Input schema / properties / claim / properties / version / descriptionAdded value: +"Semantic version string of the build being evaluated, e.g. '2.1.0'."Input schema / properties / fail_fast / descriptionPrevious value: -"Halt pipeline on first VIOLATION (spec default)"New value: +"When true (default), halt the pipeline on the first VIOLATION verdict and skip remaining gates. Set to false to run all gates and collect every verdict."veritas_security_gate16 fields changedInput schema / properties / claim / descriptionPrevious value: -"Full or partial VERITAS BuildClaim object"New value: +"A VERITAS BuildClaim object containing all declared primitives, operators, regimes, boundaries, loss models, evidence items, cost vectors, and policy configuration needed for deterministic gate evaluation. All fields are optional for partial evaluation — only the fields relevant to the gate being invoked are required."Input schema / properties / claim / properties / attack_suite / descriptionAdded value: +"AttackSuite with suite_id and list of Attack transforms (InflateBound, RemoveEvidence, PerturbParam, PerturbEvidence) for adversary gate."Input schema / properties / claim / properties / boundaries / descriptionAdded value: +"Named boundary constraints (e.g. 'CAPEX_USD <= 100000') that the claim must satisfy."Input schema / properties / claim / properties / commit / descriptionAdded value: +"Git commit SHA for reproducibility and audit trail."Input schema / properties / claim / properties / cost / descriptionAdded value: +"CostVector with optional fields: compute_flops, memory_bytes, wall_clock_s, capital_usd, coordination_agents."Input schema / properties / claim / properties / cost_bounds / descriptionAdded value: +"Upper bounds for each cost component. Utilization = max(cost_i / bound_i). Values must be > 0."Input schema / properties / claim / properties / dependencies / descriptionAdded value: +"SBOM-style dependency manifest for supply-chain analysis: package names, versions, registries, and integrity hashes."Input schema / properties / claim / properties / evidence / descriptionAdded value: +"Evidence items, each with id, variable, value (Numeric or Categorical), timestamp, method, provenance, and optional dependencies."Input schema / properties / claim / properties / loss_models / descriptionAdded value: +"Named loss functions as ArithmeticExpr over primitives, with optional upper bounds."Input schema / properties / claim / properties / operators / descriptionAdded value: +"Declared operators with name, arity, input primitive names, output primitive name, and totality flag."Input schema / properties / claim / properties / policy / descriptionAdded value: +"PolicyConfig overrides: hash_alg, solver_backend, timeouts, thresholds. Defaults to VERITAS Omega v1.3.1 canonical values if omitted."Input schema / properties / claim / properties / primitives / descriptionAdded value: +"Declared typed variables with name, domain (Interval/EnumSet/FiniteSet), optional units, and description."Input schema / properties / claim / properties / project / descriptionAdded value: +"Unique project identifier, e.g. 'omega-brain-mcp'."Input schema / properties / claim / properties / regimes / descriptionAdded value: +"Named operating regimes, each with a predicate ConstraintExpr over declared primitives."Input schema / properties / claim / properties / security / descriptionAdded value: +"Security posture declaration: SAST results, secret scan findings, injection surfaces, auth boundaries, and TLS/crypto configuration."Input schema / properties / claim / properties / version / descriptionAdded value: +"Semantic version string of the build being evaluated, e.g. '2.1.0'."veritas_type_gate16 fields changedInput schema / properties / claim / descriptionPrevious value: -"Full or partial VERITAS BuildClaim object"New value: +"A VERITAS BuildClaim object containing all declared primitives, operators, regimes, boundaries, loss models, evidence items, cost vectors, and policy configuration needed for deterministic gate evaluation. All fields are optional for partial evaluation — only the fields relevant to the gate being invoked are required."Input schema / properties / claim / properties / attack_suite / descriptionAdded value: +"AttackSuite with suite_id and list of Attack transforms (InflateBound, RemoveEvidence, PerturbParam, PerturbEvidence) for adversary gate."Input schema / properties / claim / properties / boundaries / descriptionAdded value: +"Named boundary constraints (e.g. 'CAPEX_USD <= 100000') that the claim must satisfy."Input schema / properties / claim / properties / commit / descriptionAdded value: +"Git commit SHA for reproducibility and audit trail."Input schema / properties / claim / properties / cost / descriptionAdded value: +"CostVector with optional fields: compute_flops, memory_bytes, wall_clock_s, capital_usd, coordination_agents."Input schema / properties / claim / properties / cost_bounds / descriptionAdded value: +"Upper bounds for each cost component. Utilization = max(cost_i / bound_i). Values must be > 0."Input schema / properties / claim / properties / dependencies / descriptionAdded value: +"SBOM-style dependency manifest for supply-chain analysis: package names, versions, registries, and integrity hashes."Input schema / properties / claim / properties / evidence / descriptionAdded value: +"Evidence items, each with id, variable, value (Numeric or Categorical), timestamp, method, provenance, and optional dependencies."Input schema / properties / claim / properties / loss_models / descriptionAdded value: +"Named loss functions as ArithmeticExpr over primitives, with optional upper bounds."Input schema / properties / claim / properties / operators / descriptionAdded value: +"Declared operators with name, arity, input primitive names, output primitive name, and totality flag."Input schema / properties / claim / properties / policy / descriptionAdded value: +"PolicyConfig overrides: hash_alg, solver_backend, timeouts, thresholds. Defaults to VERITAS Omega v1.3.1 canonical values if omitted."Input schema / properties / claim / properties / primitives / descriptionAdded value: +"Declared typed variables with name, domain (Interval/EnumSet/FiniteSet), optional units, and description."Input schema / properties / claim / properties / project / descriptionAdded value: +"Unique project identifier, e.g. 'omega-brain-mcp'."Input schema / properties / claim / properties / regimes / descriptionAdded value: +"Named operating regimes, each with a predicate ConstraintExpr over declared primitives."Input schema / properties / claim / properties / security / descriptionAdded value: +"Security posture declaration: SAST results, secret scan findings, injection surfaces, auth boundaries, and TLS/crypto configuration."Input schema / properties / claim / properties / version / descriptionAdded value: +"Semantic version string of the build being evaluated, e.g. '2.1.0'."v1.0.0omega_brain_reportomega_brain_statusomega_cortex_checkomega_cortex_steeromega_executeomega_ingestomega_log_sessionomega_preload_contextomega_rag_queryomega_seal_runomega_vault_searchomega_write_handoffveritas_adversary_gateveritas_claeg_resolveveritas_claeg_transitionveritas_compute_qualityveritas_cost_gateveritas_dependency_gateveritas_evidence_gateveritas_incentive_gateveritas_intake_gateveritas_math_gateveritas_mis_greedyveritas_nafe_scanveritas_run_pipelineveritas_security_gateveritas_type_gateMost tools have distinct purposes with clear boundaries, such as omega_brain_report vs. omega_brain_status or omega_rag_query vs. omega_vault_search. However, some overlap exists in the VERITAS gates where multiple gates (e.g., veritas_evidence_gate, veritas_math_gate) serve similar high-level validation functions, which could cause minor confusion without careful reading of descriptions.
Tool names follow a highly consistent snake_case pattern with clear prefixes (omega_, veritas_) that group related functionality. The naming is predictable and organized, making it easy to identify tool categories and purposes at a glance.
With 27 tools, the count is borderline high for a single server, potentially overwhelming for agents. While the tools cover comprehensive governance and verification domains, the set might benefit from consolidation or splitting into more focused servers to improve usability.
The tool set provides complete coverage for its domains: Omega Brain offers full lifecycle management (ingest, query, execute, log, seal) and VERITAS includes all 10 gates plus supporting utilities. No obvious gaps exist; agents can perform end-to-end workflows without dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
Trust gate for AI agents: multi-model adversarial consensus, signed and verifiable verdicts.
Agent-native security, trust, reliability, data and procurement tools for AI workflows.
Runtime AI governance: decision gates, human approval, hash-chained audit, compliance mapping.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/VrtxOmega/omega-brain-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
