VAPA Architecture Overview
VAPA Slot Architecture
The architecture of VAPA is built on a single premise: give the power back to the user.
The prevailing direction in the AI industry is to create “smarter” interfaces that rely on natural language to hide the underlying complexity. The problem is that most people don’t know where to start, they don’t understand how the system works, and they aren’t aware of what the AI is truly capable of. VAPA solves this by refusing to hide the controls. It provides a small, robust CORE that gives the user maximum customisation and direct access to the power of AI.
At the heart of this architecture is the 14-Module Control Matrix. This system clearly defines where data resides and who governs it. While the Core handles the “Bootstrap” (C1) and “Vulcan Logic” (C7), the vast majority of the system—including Identity, Settings, and Help—is driven by the user’s own data.
VAPA CORE Modules (C1–C14)
C1 – Bootstrap Process
The initialisation engine that sets identity, reports on the environment, and lists available files. It is strictly report-only and does not load or activate sub-files, serving as the session’s starting point.
C2 – Identity
Displays a four-line welcome block and version number at startup. It outputs a static text definition describing VAPA as a modular framework designed for enhanced user control and portability.
C3 – Environment Report
A report-only module that detects and narrates the host platform, backend type, and tool capabilities. It performs a headers-only scan to report the availability and versioning of CORE, DATA, and USER slot files without applying any settings.
C4 – Settings
The runtime engine that stores and validates all active VAPA configurations. It acts as the in-memory working copy of the D4 Registry, enforcing type checks and constraints on updates while providing a stable data interface for all other modules.
C5 – Commands
The deterministic parser and router that translates ~ prefixed input into structured requests. It normalises command tokens, handles universal scope operators (/s), and directs commands to their target modules using the D5 Registry as its routing map.
C6 – Help System
A thin CORE router and renderer that dynamically assembles help content. It pulls command definitions from D5, setting schemas from D4, and topic narratives from D6, annotating the output with current runtime values from C4 to provide contextual guidance.
C7 – Vulcan Logic
The CORE reasoning baseline that enforces a logical, neutral, and emotionally detached style. It ensures all outputs are structurally explicit and free of moral framing or assumptions, serving as the underlying standard regardless of active personas or settings.
C8 – Alter-Ego Slots
The project anchor slot that defines a session’s intent and dependencies. Activating an AE resets VAPA to defaults and loads a specific stack of Assistant (C9), Custom (C10), and Patch (C11) slots, ensuring exactly one project-level configuration is active at a time.
C9 – Assistant Slots
Reusable functional expert slots that encode specialised behaviours and can be active simultaneously. AS slots layer composable capabilities onto the session without resetting VAPA defaults, and may include inline data or references to external resources while respecting global preferences and C12’s precedence rules.
C10 – Custom Slots
Flexible, user-centric preference files that layer global style and settings onto a session. CU slots allow multiple preference sets to be active at once, providing a “user flavour” layer that C12 merges with project-specific logic while respecting the C7 Vulcan baseline and C14 security constraints.
C11 – Patch Slots
Temporary, high-priority override files for short-term fixes and experiments. PT slots provide the strongest user-content layer in the stack but are narrowly scoped and intended to be migrated into stable AE, AS, or CU slots to prevent long-term workflow fragmentation.
C12 – Session Manager
The runtime orchestrator that manages the active slot stack and reconciles settings in C4. It assembles a single set of effective instructions for each turn and provides structured status reports, ensuring all session logic is unified and validated by C14 – Security before execution.
C13 – VAPA Builder
The interactive engine for creating and validating VAPA files. It scaffolds, clones, and migrates USER slots (AE, AS, CU, PT) using canonical templates, ensuring structural integrity and providing light validation for settings and security without altering the live runtime state.
C14 – Security & Privacy Services
Provides the user with active tools to harden their session and scan their data. It manages the Secure (~s) command group, enabling file-probing for malware, privacy-mode toggles, and threat-analysis filters, ensuring the user has explicit control over their security and privacy posture.
VAPA Modules Control Matrix
The VAPA Core has 14 sections.
The following diagram describes the planned location and control of VAPA Core functionality and data
| Module | CORE | DATA | USER |
|---|---|---|---|
| C1 – Bootstrap Process | 5% | 95% | |
| C2 – Identity | 1% | 99% | |
| C3 – Environment Report | 1% | 99% | |
| C4 – Settings | 100% | override | |
| C5 – Commands | 5% | 95% | override |
| C6 – Help System | 1% | 99% | |
| C7 – Vulcan Logic | 100% | override | |
| C8 – Alter‑Ego (slots) | 100% | ||
| C9 – Virtual Assistants (slots) | 100% | ||
| C10 – Custom Settings (slots) | 100% | ||
| C11 – Hot Patches (slots) | 100% | ||
| C12 – Session Manager | 1% | 99% | |
| C13 – VAPA Builder | 1% | 99% | |
| C14 – Security | 10% | 90% |
VAPA CORE and DATA is a strict separation of logic from definitions:
- CORE (The Engine): Contains the functional logic, rules, and processes (C1–C14). It is the “software” that executes commands, manages the session, and enforces reasoning styles. CORE knows how to do things but does not hard-code what the specific options or values are.
- DATA (The Registry): Contains the static definitions, schemas, and metadata (D1–D14). It is the “database” or “spec” that defines which settings exist (D4), what commands are valid (D5), and what the help topics say (D6).