The 7 Axioms
Appgrammar's 30+ tools are not arbitrary. They are organized around 7 axioms about software structure and AI agent behavior. Each axiom identifies a fundamental property and the tools that operate on it.
Axiom I -- Compression
Knowledge compresses. Execution expands.
An entire application's architecture can be reduced to a compact blueprint. The blueprint is small; the codebase it produces is large. This asymmetry is the core value proposition: compress once, execute many times.
Tools: appgrammar_create, appgrammar_decompile, appgrammar_holographic_doc
create compresses a text description into a structured blueprint. decompile compresses an existing codebase back into one. holographic_doc generates a multi-dimensional documentation artifact from a blueprint -- a compressed view of what would otherwise require reading every file.
Axiom II -- Context
Agent quality degrades with context size.
LLMs produce worse output as their context window fills up. Appgrammar counters this by delivering steps one at a time via a token chain, keeping only what the agent needs in context at any given moment.
Tools: appgrammar_start, appgrammar_next, appgrammar_swarm_partition, appgrammar_semantic_rollback
start and next implement stage-based execution that keeps context minimal. swarm_partition splits a blueprint into parallel execution swarms so multiple agents can work on independent modules simultaneously. semantic_rollback captures intent-level state that can be restored even after structural changes.
Axiom III -- Governance
Ungoverned agents are liabilities.
An AI agent building software without guardrails can produce insecure, untested, or structurally unsound code. Governance tools let you validate and harden blueprints before execution.
Tools: appgrammar_inoculation, appgrammar_phenotyping
inoculation injects adversarial test cases to harden a blueprint against common failure patterns. phenotyping analyzes the observable characteristics and output patterns of an appgrammar.
Axiom IV -- Architecture
Structure is composable, forkable, heritable.
Software architecture is not monolithic. Modules can be extracted, combined, and inherited. Appgrammar treats blueprints as composable units with well-defined module boundaries.
Tools: appgrammar_breed, appgrammar_fork, appgrammar_splice, appgrammar_shatter, appgrammar_weave
breed merges two appgrammars by analyzing module graphs and resolving conflicts. fork creates an independent copy. splice joins two blueprints at compatible module boundaries. shatter decomposes a blueprint into atomic micro-appgrammars. weave reassembles multiple modules into a unified blueprint with cross-module integration paths.
Axiom V -- Ecosystem
When intent is legible, the ecosystem is navigable.
A registry of appgrammars is only useful if you can find what you need. Ecosystem tools enable discovery through structure, community behavior, and dependency awareness.
Tools: appgrammar_search, appgrammar_broadcast, appgrammar_topological_search, appgrammar_upstream_shield
search queries the registry by text. topological_search finds structurally similar appgrammars by module graph shape. upstream_shield protects against breaking changes from dependency updates. broadcast notifies subscribers of changes.
Axiom VI -- Transformation
Intent is invariant under transformation.
You can change the technology stack, coding style, or level of detail of an appgrammar without changing what it builds. The architectural intent is preserved across transformations.
Tools: appgrammar_transmute, appgrammar_distill, appgrammar_amplify, appgrammar_style_transfer
transmute converts a blueprint from one tech stack to another (e.g., React to Vue, PostgreSQL to MongoDB). distill strips a blueprint to its essentials, removing redundancy. amplify expands modules with additional tests, documentation, and detail. style_transfer applies the coding conventions of one appgrammar onto another.
Axiom VII -- Algebra
Structure admits a closed algebra.
Appgrammars can be combined using set-theoretic operations. Subtract modules, compute intersections, find symmetric differences, or introduce controlled mutations. The result is always a valid appgrammar.
Tools: appgrammar_subtract, appgrammar_intersect, appgrammar_difference, appgrammar_fuzz, appgrammar_update
subtract removes all modules present in one appgrammar from another. intersect returns only the modules shared across multiple blueprints. difference highlights what is unique to each of two blueprints. fuzz introduces controlled variations to test robustness and discover edge cases. update closes the feedback loop: it compares the current codebase against the blueprint, identifies structural changes, and applies them — updating in place for owners or creating a fork for non-owners.