> For the complete documentation index, see [llms.txt](https://docs.codna.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.codna.ai/reference/glossary.md).

# Glossary

## Core concepts

**Snapshot** — An immutable, exact commit of a repository tree. Every step Codna runs is bound to a snapshot, so results are reproducible and a stale response can't be substituted for a fresh one.

**Connector** — A registered source for a repository — a local directory (read through the Algenta SDK) or a fetched git URL — that a snapshot is pinned to.

**Repository graph** — The deterministic symbol-and-dependency graph the engine builds from a snapshot: which functions call which, which modules import which, where each symbol is defined and referenced. Built with no LLM and \~0 tokens.

**Blast radius** — The set of symbols a change to a given location could affect. Computed from the repository graph and used both to scope the evidence bundle and to estimate regression risk.

**Evidence bundle** — The compact, issue-specific slice of code and structure the engine hands the agent, instead of the whole tree. Its size is dynamic — sized to the repo, the issue, and the verification path — and reported per run.

**Reduction ratio** — The token-reduction metric: how much smaller the evidence bundle is than reading the raw source tree would be. Reported as the `context` field in `codna fix` output.

**Verified-agentic** — Codna's bundled agent planner, referenced by the model id `repository.verified_agentic_v1`. A sentinel that routes a request to the local agent-core runtime rather than naming a specific provider model. See [Models & BYOK](/concepts/models-and-byok.md).

**Risk gate / simulation** — Before a patch is applied, it is simulated against the graph to estimate blast radius and regression risk; a governing gate checks that risk against a calibrated floor. Only a valid `simulation_id` lets a change proceed.

## Security Autofix

**Reachability verdict** — One of four honest classifications every scanner finding receives:

| Verdict                | Meaning                                                                 | Autofix-eligible                      |
| ---------------------- | ----------------------------------------------------------------------- | ------------------------------------- |
| `exploitable`          | An independent source-to-sink taint path is proven                      | Yes (policy default)                  |
| `production-reachable` | The operation is callable in production; taint not independently proven | Only with an explicit policy override |
| `unreachable`          | No path, under a complete and sound analysis envelope                   | Never                                 |
| `unknown`              | No path under an incomplete or unsupported envelope                     | Never                                 |

**Analysis envelope** — The completeness of the analysis for a given `(language, framework, build_mode)`. Codna reports `unreachable` only under a complete, sound envelope; otherwise "no path found" is reported as `unknown`, never `unreachable`.

**Closure** — An independent proof that the original security obligation is closed (gate G7). Distinct from reachability: a sink can stay production-reachable while the obligation is closed by a recognized sanitizer/barrier.

**Attestation** — A signed evidence bundle (HMAC, via `CODNA_ATTESTATION_KEY`) passed from the analysis worker to the privilege-separated PR writer, so the writer can verify what it's opening without re-running analysis.

**Privilege separation** — The split between the analysis domain (reads code, generates patches, no write token) and the writer domain (`codna secure-open-pr`, holds a narrowly-scoped write token, opens the draft PR only after verifying the attestation).

**The G-gates (G1–G9)** — The nine conditions a fix must satisfy; a draft PR opens only on their logical AND, and a single failure is named in the report:

| Gate | Condition                         |
| ---- | --------------------------------- |
| G1   | Immutable provenance              |
| G2   | Baseline reproduction             |
| G3   | Policy-eligible proof             |
| G4   | Patch integrity (anti-evasion)    |
| G5   | Regression safety                 |
| G6   | Scanner confirmation              |
| G7   | Independent closure proof         |
| G8   | No alternate or new vulnerability |
| G9   | Attested handoff, base unchanged  |

## Platform

**Algenta SDK** — Codna's repository-intelligence engine, run **locally and in-process** inside `codna` (not a cloud service you call). It builds the graph, localizes issues, and simulates patches.

**Telys** — Codna's on-device memory kernel, bundled in the wheel. Powers the local `.codna-memory` index and `codna_recall`. See [Code Memory](/concepts/memory.md).

**Sidecar** — The compiled agent-core runtime bundled in the wheel. Codna launches it locally to run the agent; there is no external service to start.

## See also

* [How It Works](/concepts/concepts.md) — the concepts above in narrative form.
* [Security Autofix](/guides/security-autofix.md) — the full reachability + gate flow.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.codna.ai/reference/glossary.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.