Skip to content
Technical Wiki · Systems

Ajenda Architectural Graph

A persistent machine-readable representation of Ajenda software structure, ownership, dependencies, selected invariants, and proof relationships.

Wiki index
Active development and CI capability

01

Why project context is not enough

Knowing that files, routes, tests, and imports exist does not by itself establish which component owns a decision, which invariant governs a change, what the real blast radius includes, or which proof is required beyond the edited file. Those relationships otherwise have to be reconstructed during each change analysis.

02

Represented relationships

The canonical graph contains module relationships and selected function-level nodes together with metadata such as decision roles. Relationships include defined_in, calls_function, and tests_function, alongside architecture roles, semantic boundaries, dependency edges, selected invariants, and proof information used by development tooling.

03

Current use

Ajenda development uses graph state for dependency and impact analysis, decision ownership, graph-aware proof selection, selective-CI reasoning, completeness auditing, architecture decision composition, semantic checks, and selected function-level diagnosis. It is development and CI infrastructure, not customer-facing Ajenda runtime functionality.

Evidence boundary

What this entry supports

The public interactive view is a reviewed projection derived from Ajenda’s canonical development graph. It is deliberately smaller than the full internal graph and should not be interpreted as complete public exposure of the repository architecture.

Related material