Decapod boundary

Type: agentic-system-analyses/types/agentic-system-boundary.md

Boundary and evidence

This run examines how Decapod supplies context, preserves agent work, coordinates custody and gates accepted delivery. The target is the complete shipped repository-native governance layer, not an autonomous coding-agent harness or just its knowledge API. It qualifies as an extension or tool mechanism serving model-dependent agent work. Its shipped agent contracts require agents to consult context, record work and respond to governance feedback. An optional decision-provider implementation also submits repository state to Jev. These facts establish scope, not host compliance or model quality (SRC-1, AGENTS.md, src/decapod/core/decision_provider.rs).

Decapod is a Rust CLI that agents use throughout development. It reads the project's configuration and recorded work, checks the relevant requirements, and returns context or a next step. The agent writes the code and operates the project's tools, including configuring builds and CI when needed. --- README.md

The boundary is whole-system: it includes the CLI and structured RPC, embedded constitution and agent documentation, generated host entrypoints, project overrides and living specifications, governance documents, database-backed knowledge and decisions, task/session/workspace custody, context retrieval and capsules, validation and publication, optional service adapters, and shipped build/release/CI drivers and evaluators. Same-repository callers and drivers remain inside the boundary. The table below covers every top-level tracked entry; inclusion is functional scope, not a claim that every file has been inspected.

Initial implementation tracing establishes more than a library surface. src/main.rs invokes decapod::run; Cargo.toml declares that executable, the library and feature-gated utility binaries. src/decapod/lib.rs parses commands, dispatches knowledge add/search/promotion to the database plugin, exposes RPC context resolution and recommends persistence and subsequent queries. src/decapod/plugins/knowledge.rs admits provenance-labelled entries, searches retained active rows, and implements expiry-based maintenance; this initial read does not establish an automatically scheduled decay caller. src/decapod/core/governance_document.rs reloads and writes governed sections. src/decapod/core/project_specs.rs reads project configuration and authored specs for later context, consumed by the RPC handler. Publication checkpoint verification calls governance/workspace checks. Thus state production, admission, maintenance, reload and consumption are all included, not cut at the API boundary (SRC-1, the paths named here).

fn main() { if let Err(error) = decapod::run() { eprintln!("{error}"); std::process::exit(1); } } --- src/main.rs

op: "store.query".to_string(), reason: "Retrieve prior decisions and knowledge relevant to current task" .to_string(), required_params: vec!["kind".to_string()], --- src/decapod/lib.rs

The shipped prompts are evidence about intended host behavior, not instructions to this analyst. AGENTS.md, CLAUDE.md, CODEX.md and GEMINI.md prescribe orientation, pre-inference context, durable trajectory records and living-spec maintenance. The build script ingests assets/constitution.json and docs/agent/ into embedded content, while the constitution CLI returns embedded nodes or scoped fragments. Activation-conformance fixtures specify how to evaluate whether external hosts actually follow those entrypoints. Test source is not an observed host run (SRC-1, assets/build/compress_constitution.rs, src/decapod/core/constitution_cli.rs, tests/fixtures/activation_conformance/README.md).

A host must receive only the task intent below and operate in a clean checkout. The repository's generated entrypoint is the activation contract; the host must not be given a hand-translated Decapod command sequence. --- tests/fixtures/activation_conformance/README.md

Repository coverage

The tracked tree was enumerated at the frozen commit. “Initial read” identifies bounded inspection; “not yet inspected” means available evidence reserved for later source tracing, not an access gap. All directory descendants remain included unless explicitly excluded below.

External responsibilities and evidence limits

External model providers and coding harnesses supply reasoning, chat context, tool execution and host activation. They are deliberately excluded as implementations: this prevents conclusions about their internal loops, universal compliance with Decapod prompts or commands outside the governed surface. The Decapod-facing prompts and adapter code are included. The source itself warns about this boundary (SRC-1, README.md, docs/architecture/governed-execution.md).

Validation covers the configured requirements; Decapod cannot govern commands an agent runs outside its workflow. --- README.md

Git and repository/filesystem behavior, Rust dependencies including dactyl-db, SQLite and configured cloud storage, container engines, GitHub/Buildkite execution and optional Jev are external dependencies, not additional frozen sources. Their Decapod interfaces and shipped drivers are included. Unacquired dependency/service implementations prevent independent claims about backend internals, remote availability or end-to-end service correctness (SRC-1, Cargo.toml, src/decapod/core/decision_provider.rs, .github/workflows/ci.yml). The MCP-named documentation describes an integration limit, not evidence of a shipped MCP host:

Decapod currently provides a Decapod-specific structured RPC interface over process stdin/stdout. It does not currently implement an MCP server, MCP lifecycle, MCP resource discovery, or MCP tool discovery. --- docs/agent/mcp.md

No target execution, live-service inspection, host transcript or causal experiment was supplied or performed. This prevents observed-success, reliability-rate and causal-improvement claims. No material source path needed for classification was inaccessible. Uninspected available paths are explicitly separated from those external evidence limits.

The frozen evidence is the acquired Git checkout at 067b8f55071e13dd103779998168b4c9ffd31a79; HEAD was checked against that pin. The applicability cutoff is the opening's run date, 2026-10-14, not a claim that all documentation was independently current on that date. Later revisions, live issue content, external research links and service responses are outside the evidence boundary. Overall evidence is code-grounded, with source-native declarations retained separately as doctrine/design.

Source register