Technical documentation
Generated from the architecture wiki, whose working name for the platform is AISA Next; the product page presents it as AISA v2.0. Same platform, same state of 08.09.2026.
The trainable intellect that operates the systems behind your products. The goals explain this philosophy; the architecture specifies how expertise becomes agent profiles, reusable skills and verified knowledge, and how proven work earns greater autonomy.
AISA Next is a web-based, multi-session platform on which graphs of profiled agents run four modules for the Serdica estate: Support — the root, which classifies and identifies every client request and routes it, or lets it wait — and the three working modules it routes to: Configuration, Data and information (the former Support module's working stages) and Development (id source; defects and small extensions) (D143, D144). State of 04.09.2026. Agents work autonomously; a controlling human decides at defined gates.
Where things are documented (D145). The agent pages of the architecture chapter are module-agnostic — each states a rule and one example. Every module page opens with the module's own agent tree, then its branch of the memory tree, then its skills and tools, then its stages.
Documentation convention
Structured after ATA Spec 100 practice: numbered chapters, one subject per document, declarative present-tense statements. Every substantive statement is one of three kinds, tagged where the kind is not obvious:
- F fact — verified against code, database, memory, or a named source; the source is linked.
- P plan — a decided design statement.
- C challenge — open; needs investigation or a decision before build.
Module diagrams draw a step in one of the four states of Gating § 1b: a person decides (amber; a diamond is a gate), a signed result (green), a person decides on a signed result (two-tone), after the workflow (violet, dashed, on a dotted edge) — D148.
The goals chapter carries no diagrams (D150): the platform and the modules on it are drawn once, in Architecture § 0, each module's agent tree at the head of its module page, and every other chart in the architecture chapter. No narrative history in chapter bodies — rationale lives in the Details documents, requirement lookup in the Requirements Register, open-item lookup in the generated Challenges Register. All links are plain relative Markdown links.
Checking this wiki
The conventions above are enforced, not trusted: pwsh scripts/wiki_check.ps1 -Mermaid from the repository root (and pwsh scripts/wiki_challenges.ps1 regenerates the Challenges Register) fails on a broken relative link, an Obsidian wikilink, an F without a resolvable source, a page unreachable from this one, or a mermaid block that does not render — and prints the statement census.
The checker prints the live statement census — pages, links, F/P/C counts and diagrams. The numbers are deliberately not copied here: a hand-maintained count drifts from the thing it counts, and a stale census is worse than none. Run the gate to see them.
Chapters
The module sections (20 / 30 / 40) are folders inside 10 Architecture/, not separate top-level chapters; they hold the four module pages.
| Chapter | Documents |
|---|---|
| 00 Goals | Goals — one page: a brief for the platform, a brief per module (Support the root · Configuration · Development · Data and information, with the renames), then the goal tables with their reasoning folded in (PG · SG · CG · DG; the Details pages and the Baseline are folded into it) · Metrics · Value and ROI · Delivery · Non-Goals |
| 10 Architecture | Architecture (the section's home — the platform picture, the modules on it, and each module's agent graph) · Delivery § 1.4 (every component, its kind, its track and its done test — the phase-1 deliverable) · Software Architecture (placement, applications, libraries, plug-ins, data, dependency rules, reuse verdicts, hosting and operations) · Agent Framework (what an author declares, what the framework guarantees, and how anything publishes; § 7 points at the memory and skills page) · Agent Runtime (the loop, graph instantiation, messages, write approval, durability, case control) · Agents (the profile, the platform profiles, how the modules reach each other) · Agents Memory and Skills (one page in two parts — the memory tree's principles, the AGENTS.md protocol, the dreaming pass, the past-case index and an inherited corpus's migration; what a skill is, when one exists, its governance, its failure and three samples. The domains and the catalogues are on the module pages) · Gating (the gate set, the write classes, shape approval, the auditor, auto-confirm) · Trust and Data · Failure and Recovery · UI (the screens, and the wireframes for both surfaces) · Whitelabel Catalogue (every value that is configuration, with its default and scope) · Data Model (the SRD_SUPPORT DDL — scripts, schema diagram, guards) · Contracts (the five platform seams with validator and fixtures, the eleven inter-stage drafts, the API, the realtime events, the connector SDK) |
| 10 Architecture / UI wireframes | Operator wireframes (fourteen screens — the chat is the workspace) · Client wireframes (four screens) |
| 10 Architecture / 20 Configuration | Configuration Module (its agent tree, memory branch and skills at § 0) · Components (what has to be built: agents, skills, projections, contracts) · Configuration Module § 8 (the architecture test: 8 real cases) · stages: Normalization · Abacus · IPAL · Offer · Serdica · estate mechanics: Rating Files · Quote Verification · Write Envelopes · Shared Vocabulary · Translations · Factor Sources |
| 10 Architecture / 30 Development | Development Module (its agent tree, memory branch and skills at § 0; the stages; eight live changes) · Components · Planning (placement, the branch set, the brief) · Implementation · Test and Corrections · Deployment Scripts · Deploy and Reversal |
| 10 Architecture / 40 Support | Support Module (the root module — intake, classification, the route, waiting, closure; its agent tree at § 0) · Data and Information Module (the former Support's working stages S2–S8; its agent tree, memory branch and the 35-shape skill catalogue at § 0) · Components (six investigator tracks, the nine mechanics, the 35 shapes in four build groups) · Case Studies (ten cases, twelve tickets) + stages: Classification · Investigation · Solution Take · Application and Verification · Precipitation |
| 90 Reference / Decision register | Decision register (the taken decisions) |
| 90 Reference | Live registers — Open Decisions (the one page to decide from: who owes which answer) · Requirements Register (every requirement, and the document that elaborates it) · Challenges Register (generated from every C in the wiki) · GlossaryEvidence — Measurements 2026-09-02 (everything measured that day, in five passes: § TM the ticket archive · § TT agent hours against the human estimate · § TB v1 retrieval · § DB the customer databases · § RE the repositories) · Product Configurator (the sibling that ran first: § SRC the artifact · § P the twenty proven patterns · § A/C/Q the three configurator documents reconciled) · Schema Quirks (names, keys and errors that are not what you would guess — observations, not truth) Record — Challenge Rounds 2026-09-02 (how the open items were worked down that day: § GA the goals audit · § CS round 1 · § R2 round 2 — settled conclusions are decisions now; what is kept is the reasoning and what is still open) |
| 90 Reference / Product configurator documents | Requirements · Design · Product design |
The working framework
P Case-driven architecture test: Case journeys traces all 68 typical cases through the existing screens, backend records, agent tasks, post-result learning and the next similar request. Its interactive walkthrough and falsifying examples are the implementation acceptance inventory.
P For developers: start with the Implementation Guide, then Modules, Model Execution and Agent Runtime. They name the code boundaries, executable declarations, LLM protocol and durable state; the module stages supply the domain detail.
A common frame the modules instantiate — not mandatory rails; each module defines its own stages, gates, and proof levels per its kind of work and task shape.
- Work runs as cases executed by graphs of profiled agents: a root orchestrating agent per module → stage agents → profiled sub-agents (Agents; each module's tree at its module page § 0).
- Agents research freely — consults, addressed to a domain (Agents § 5, D92), are normal. Doubt and dead ends travel upward; only the root agent hands over to the human.
- The human always decides: writes to protected targets, materially missing information, and the module's defined gates — or by policy once a shape has earned it (Gating § 9, D70).
- A session is stoppable, resumable, deletable; many people can open it, exactly one operates it (Agent Runtime).
- Every action lands in a tool-parsable audit log; metrics are parsed, never counted by agents (Metrics).
- Every stage verifies itself and reports the level actually reached; every module keeps eval sets that re-run when its memory, skills, or models change (Architecture common rules).
- All agents share one memory: a tree of domains, one
AGENTS.mdindex per node, one writing profile per domain (Agents § 0.1), writes only inside the own domain (Agents Memory).