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.
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.
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. |
Relations and history
Entities are connected by typed relations — for example a release is
part_of a component, a decision derives_from a
requirement, a component fulfills a requirement. The engine
validates relation targets, and it keeps a full version history of every
entity automatically, so you can always answer "what changed, when, and
why".