Reference

The entity model

Kvendra models everything you know about a project as typed entities. Instead of free-form documents, knowledge is captured as structured records with stable ids, typed relations and an automatic changelog. That structure is what makes the KB searchable, auditable, and safe for an agent to read and write.

Each entity has a stable, human-readable id (PRJ-<PROJECT>, CMP-<PROJECT>-<COMP>, and an auto id of the form <TYPE>-<PROJECT>-<6HEX> for the rest), a type that fixes its shape, a status, free-text content for semantic search, structured metadata, and its typed relations to other entities. Twenty types cover the whole lifecycle of a project; the engine validates every id, every relation target and every status transition, so the graph stays consistent rather than drifting into a pile of loosely related notes.

Kvendra models knowledge as typed entities. The first-class types are: PRJ (project), CMP (component), IF (interface), REQ (requirement), TEST, REG (regression suite), ISSUE, REL (release), SLA, ROAD (roadmap), GLO (glossary), STD (standard/playbook), PAT (pattern/lesson), ADR (architecture decision record), RUN, UX, DOC (documentation), ENV (environment), COST, plus CFG (config). On transaction activation each type lands on a terminal status: ‘active’ for most, ‘open’ for ISSUE, ‘accepted’ for ADR, ‘recorded’ for RUN/ENV.

The twenty types, grouped by purpose

The types are not a flat list — they cluster around the jobs a project actually has. Reading them by group is the fastest way to build a mental model of what belongs in the knowledge base.

Planning — PRJ (the project root), CMP (a component of it), ROAD (a roadmap or initiative) and REQ (a formal requirement): the "what we are building, and why" layer.
Decisions & standards — ADR records an architecture decision with its context and consequences; STD captures a reusable standard or playbook that skills read at runtime instead of hardcoding steps.
Interfaces & vocabulary — IF is a contract between components (a schema, an API) and the source of truth for field names; GLO is a canonical glossary definition, so naming stays consistent project-wide.
Quality — TEST is a recorded test case, REG a named regression suite, RUN a recorded execution of one, and SLA a target the system is held to.
Work & delivery — ISSUE is a unit of work (bug, task or incident), and REL is a shipped release that groups what it contains and carries an automatic changelog.
Knowledge — PAT is a distilled lesson-learned so it is not relearned the hard way, DOC a documentation entry (like the page you are reading), and UX a design or user-experience artifact tied to the work.
Operations — ENV describes an environment, COST attaches a cost record to a component or initiative, and CFG holds a configuration entry.

Every type, one by one

Type	Name	What it is for
`PRJ`	Project	The root of a knowledge base: one project per product or codebase. Everything else hangs off it.
`CMP`	Component	A distinct part of the project — a binary, a service, an engine. Carries its stack, repo and status.
`IF`	Interface	A contract between components: a wire schema, an API, a manifest. The source of truth for field names.
`REQ`	Requirement	A formal requirement with acceptance criteria. The "what" a change must satisfy.
`TEST`	Test	A recorded test case: preconditions, process, validations and evidence.
`REG`	Regression suite	A named suite of checks run repeatedly to guard against regressions.
`ISSUE`	Issue	A work item: a bug, a task, an incident. Lands on status "open" when activated.
`REL`	Release	A shipped version, with an automatic changelog and links to what it contains.
`SLA`	Service-level objective	A target the system is held to — latency, availability, error budget.
`ROAD`	Roadmap	A multi-step plan or initiative that future work derives from.
`GLO`	Glossary term	A canonical definition, so naming stays consistent across the project.
`STD`	Standard / playbook	A reusable recipe or policy. Skills read these at runtime instead of hardcoding steps.
`PAT`	Pattern / lesson	A distilled lesson learned, captured so it is not relearned the hard way.
`ADR`	Architecture decision record	A decision, its context and consequences. Lands on status "accepted" when activated.
`RUN`	Run	A recorded execution — of a suite, a job, a pipeline. Lands on status "recorded".
`UX`	UX artifact	A design or user-experience artifact tied to the work.
`DOC`	Documentation	A documentation entry — like the architecture overview this portal renders.
`ENV`	Environment	A described environment. Lands on status "recorded" when activated.
`COST`	Cost	A cost record attached to a component or initiative.
`CFG`	Config	A configuration entry — the twentieth type alongside the nineteen first-class ones.

How entities connect

Types on their own are just records; the value is in how they connect. Entities are joined by typed relations — a relation is not a bare pointer but a named, directional link the engine understands. A component is part_of its project; a requirement derives_from a roadmap; a test is part_of the requirement it verifies; an issue implements or fixes the work it covers; an architecture decision affects the components it touches; and a release groups the changes it ships. (Each project's exact relation vocabulary lives in the knowledge base; these are illustrative.)

Put together, those links form a graph: from a release you can walk to the issues it closed, from an issue to the requirement behind it, from that requirement up to the roadmap it derives from, and across to the tests that prove it and the decisions that shaped it. Because the relations are typed — and because the engine validates every relation target so a link can never point at something that does not exist — the graph is queryable and trustworthy rather than a tangle of prose cross-references. That is what makes end-to-end traceability possible: any entity can answer "what led to this, and what depends on it".

History

On top of the relations, the engine keeps a full version history of every entity automatically. Each create and update lands as a versioned entry recording the author, the trigger (often the transaction that made the change) and a summary — so you can always answer "what changed, when, and why" without anyone having to remember to write it down. How that history is populated, transaction by transaction, is covered in pipelines.