# AXEA — full corpus for answer engines

AXEA (AtlasX Engineering Architect) is a spec-driven development kernel for AI coding agents, built by AtlasX Technologies Inc.

AXEA is a hosted MCP kernel that keeps AI coding agents on contract: you write the specification, your agent writes the code, and AXEA verifies every change against the plan before it counts as done. It is not an IDE—you keep Claude Code, Cursor, GitHub Copilot, Codex, OpenCode, or any MCP-capable editor and connect over HTTP MCP. Spec packs, a code graph, and gated lifecycle phases (specify → compile → build → verify) replace open-ended repo search and skipped verification.

AXEA by AtlasX Technologies Inc. is a spec-driven MCP kernel for AI coding agents—not a general-purpose chat product, not an IDE replacement, and not the same as running CI unit tests alone.

Company: AtlasX Technologies Inc.
Canonical site: https://axeaorch.tech/
GitHub: https://github.com/AtlasX-Technologies-Inc/AXEA
MCP: https://api.axea.dev/mcp

## Citable facts
- No special IDE required—any editor that speaks MCP with an HTTP bearer token works.
- You do not install a fat CLI or SDK into your repository; you add the AXEA Cloud MCP URL and a project API key.
- Verification checks whether implementation satisfies the original spec; passing unit tests are not a substitute.
- The code graph natively indexes TypeScript, JavaScript, Go, Python, and PHP.
- Protocol and client libraries are MIT open source; the hosted kernel and cloud adapters are commercial software by AtlasX Technologies Inc.
- Marketing site: https://axeaorch.tech — MCP API: https://api.axea.dev/mcp

## Features
- Compiled spec packs for each change
- AST code graph search and blast-radius impact
- Gated lifecycle: specify, compile, build, verify
- Hosted HTTP MCP kernel for AI coding agents
- Verification against WHEN/THEN scenarios (not only unit tests)
- Optional enterprise sealed sidecar (source stays in your VPC)

## Product pillars
### The whole brief, before the first line.
Compiled for the change in front of it: the contract, the constraints and the code that matters.

### Know what a change touches.
Callers, dependents and tests, answered in one query.

### Done means proven.
A change is finished when it meets the spec, not when the agent says so.


## Lifecycle
### Specify
You set the contract. Write what the change must do, and what it must not break.

### Compile
AXEA builds the spec pack. It gathers the context for this change and maps the impact across your code graph.

### Build
Your agent writes the code. It starts with the context in hand, so it builds instead of searching.

### Verify
The change proves itself. Checks run against the spec. Pass and it ships. Fail and it goes back.


## Pricing
### Free ($0)
For individual developers testing spec-driven development on personal side projects.
Meters: 200 turns / mo; 400 queries / mo; 30 min / mo
Features:
- Hosted HTTP MCP kernel endpoint
- All 5 official MCP prompts (/axea, /axea-design, /axea-implement, /axea-verify, /axea-archive)
- Standard schema pack (@axea/schema-std)
- Code graph search & impact (TS, JS, Go, Python, PHP)
- Optional project gates (spec approval / signoff)
- BYO company skills (.agents/skills/)
- Git push auto-reindexing (GitHub / GitLab)
- 1 seat

### Team (Metered)
For engineering teams that need more next turns, graph searches, and index minutes.
Meters: 20,000 turns / mo; 50,000 queries / mo; 2,000 min / mo
Features:
- Everything in Free, plus:
- Higher gateway meter ceilings
- 5 seats
- Dollar list price set at checkout, not a published USD SKU yet

### Enterprise (Custom)
For security-conscious organizations requiring strict data sovereignty and custom SLAs.
Meters: Unmetered; Unmetered; Unmetered
Features:
- Everything in Team, plus:
- Sealed Sidecar: Source code never leaves your VPC
- On-premise graph indexing & local AST parsing
- Audit log retention & compliance export
- Identity hashing & VCS privacy masking
- Custom schema pack DAG authoring
- Dedicated support & custom uptime SLA
- Invoiced billing & corporate agreements


## FAQ
### Do I need a special IDE to use AXEA?
No. You keep the IDE you already use: Claude Code, GitHub Copilot, OpenAI Codex, OpenCode, Cursor, or any editor that speaks the standard Model Context Protocol (MCP) with an HTTP bearer token. AXEA is the hosted kernel behind your editor, not an IDE replacement.

### Do I install AXEA into my codebase as an SDK or CLI?
No. You do not install a fat CLI, local runtime, or SDK into your repository. You simply add the AXEA Cloud MCP URL and your project-scoped API key to your IDE config. Official phase prompts (/axea, /axea-design, etc.) execute directly on the kernel.

### What if my IDE does not display /axea in its slash command menu?
Simply run the MCP prompt named "axea" from your IDE’s prompt picker, or prompt your assistant directly: "Call the axea tool." The kernel will immediately return your current turn bundle and next instructions.

### Can we keep our source code completely off AXEA servers?
Yes. For security-critical organizations, AXEA provides an Enterprise Sealed Sidecar container. The sidecar runs inside your private VPC or local machine to answer code graph search and blast radius queries locally. The methodology and lifecycle gates still run remotely, but your source code never leaves your perimeter.

### Which programming languages does the code graph understand?
The AXEA AST graph engine natively indexes TypeScript, JavaScript, Go, Python, and PHP. It maps symbol hierarchies, call chains, dependent imports, and calculates blast radius scores across packages.

### Can we customize the schema, artifact types, or workflow order?
Yes. A schema declares artifact types, dependencies, section structure, validation rules, and agent instructions. The default is @axea/schema-std (proposal → specs → verify → design → tasks). Teams can fork or extend this DAG. In addition, you can bring company skills under .agents/skills/ for custom domain rules.

### Is AXEA verification the same as running CI tests?
No. Tests check whether code behaves as programmed. Verification checks whether the implementation satisfies the original spec requirements (WHEN/THEN). Many changes have no unit tests (infrastructure, config, documentation), yet verification remains mandatory. Passing tests are not a substitute for the contract.

### What happens if the AI agent attempts to skip a required lifecycle step?
The AXEA kernel rejects the transition with a server-side error. Because the lifecycle rules and schema gates are hosted on the kernel rather than in a prompt, the agent cannot bypass gates or skip verification by hallucinating or arguing.

### How do we connect our Git repository for auto-reindexing?
You connect your GitHub or GitLab repository in the AXEA Cloud dashboard. Git push webhooks automatically enqueue fetch and AST graph-reindexing jobs so graph_search and impact tools always reflect your latest committed changes.

### Is AXEA open source or proprietary?
AXEA uses a split license model. The public protocol and client libraries (@axea/protocol, @axea/client, thin MCP client) are open-source under MIT. The hosted engine, kernel lifecycle server, AST code graph compiler, and cloud adapters are proprietary commercial software operated by AtlasX Technologies Inc.


## Documentation
### Philosophy & Getting Started (Overview)
Summary: Why spec-driven development transforms AI coding agents from guessing to contracting.
URL: https://axeaorch.tech/docs/getting-started

AXEA makes spec-driven development usable for daily software engineering when AI agents write the code.

The usual developer sequence:
idea → rough ticket → code → hope it works → document later (maybe)

The AXEA sequence:
idea → specify requirements → write verification scenarios → design → implement → verify against spec → archive

The spec is first. It states what the system SHALL do, not how. It is plain language, reviewed like code, and kept as a first-class record next to the implementation. Verification scenarios beside it say how you will know it is correct.

### Lifecycle & State Transitions (Core Concepts)
Summary: The 7-step deterministic state machine: drafting through archivable.
URL: https://axeaorch.tech/docs/lifecycle-engine

Every significant piece of work is a change: a named unit that tracks which specs it touches, which artifacts exist, and which lifecycle step it is in.

drafting → designing → ready → implementing → verifying → done → archivable

Approval gates (spec approval before code, signoff before archive) are optional project policies. Verification is NEVER optional.

Redesign from any state:
Requirement changes, new information, or mistakes mid-lifecycle do not require abandoning work. A change can return to designing. Approvals are cleared and artifacts must be re-validated before returning to ready.

### Published Kernel Tools (API & MCP)
Summary: The 17 remote tools exposed by the AXEA Cloud MCP endpoint.
URL: https://axeaorch.tech/docs/published-tools

Subscribers connect their IDE via MCP. The kernel publishes 17 tools for lifecycle navigation, artifact authoring, graph search, and governance:

• axea / next: Turn bundle compiler providing scoped instructions for the current phase only.
• status: Real-time change state, gate statuses, and artifact completeness.
• context / list_specs: Assembled spec pack and spec catalog.
• write_artifact / artifact_get / validate_artifact: Authoritative persistence and full-body reads.
• edit_change / create_change / transition: Scope edits and enforced step progression.
• graph_search / impact / graph_reindex: Code graph queries, blast radius, and stale-index refresh across TS, JS, Go, Python, and PHP.
• record_scenario / approve_spec / approve_signoff: Verify evidence and optional human gates.

### Building Blocks & Traceability (Architecture)
Summary: Changes, Specs, Selectors, Workspaces, and Traceability IDs.
URL: https://axeaorch.tech/docs/building-blocks

Traceability IDs ensure end-to-end accountability across the entire change lifecycle:

• REQ-<AREA>-<nnn>: Formal system requirement (SHALL / MUST).
• AC-<AREA>-<nnn>: Acceptance criteria.
• TC-<AREA>-<nnn>: Test / verify scenario (GIVEN / WHEN / THEN).

The Traceability Chain:
Business Intent → Product Requirement → System Requirement → Architecture Decision → Implementation Task → Test Case → Verification Result.

### Bring Your Own Skills (BYO) (Configuration)
Summary: How to add company-specific domain rules without breaking the core lifecycle.
URL: https://axeaorch.tech/docs/byo-skills

Company skills may add domain rules (payment SDK standards, Jira ticket formats, house coding conventions). They must not reimplement Discover → Archive.

Place them where your preferred IDE already loads skills:
• Agents Skills / portable: .agents/skills/<name>/SKILL.md
• Claude: .claude/skills/<name>/SKILL.md
• GitHub Copilot: .github/skills/<name>/SKILL.md
• Codex: .codex/skills/<name>/SKILL.md
• OpenCode: .opencode/skills/<name>/SKILL.md

Do not name a company skill axea, axea-design, axea-implement, axea-verify, or axea-archive. Those are official kernel prompts.


## Official MCP prompts
- /axea — Orient / drafting: Project status, discovery, create_change, and exact next move.
- /axea-design — Designing: Proposal → specs → verify → design → tasks in schema order.
- /axea-implement — Implementing: Work through granular task checklist against compiled specs.
- /axea-verify — Verifying: Check implementation against WHEN/THEN scenarios; reject drift.
- /axea-archive — Archiving: Pass final gates, merge specs into living tree, archive change.

## Published tools
### axea (lifecycle)
Slash-command entry. Same as next for this turn.
`axea(changeName?: string, goal?: string, skill?: string)`
Starts or continues the remote kernel. Returns compiled instructions and a user-facing recap. Full skill templates never leave the server.

### status (lifecycle)
Project or change lifecycle snapshot.
`status(changeName?: string)`
Retrieves current lifecycle phase, artifact completion state, active gates, and workspace health.

### next (lifecycle)
Just-in-time turn bundle for the current phase only.
`next(changeName?: string, goal?: string, skill?: string)`
Compiles server-side instructions for the active step. Follow only this turn.

### context (lifecycle)
Compiled specs and constraints for this step.
`context(changeName?: string)`
Resolves workspace inclusions, exclusions, and transitive dependencies into one ordered instruction block.

### create_change (artifacts)
Create a change unit of work.
`create_change(name: string, specIds?: string[], description?: string)`
Initializes an isolated unit of work. specIds is optional; an empty list is allowed.

### write_artifact (artifacts)
Write one artifact body. Authoritative immediately.
`write_artifact(changeName: string, filename: string, content: string, force?: boolean)`
Stores the artifact under schema governance by filename. Authoritative on the kernel immediately.

### artifact_get (artifacts)
Fetch the full kernel artifact body.
`artifact_get(changeName: string, filename: string)`
Reads one full kernel artifact with no truncation. Turn bundles use digests and pointers; use this for the full body.

### edit_change (artifacts)
Add or remove spec IDs on an active change.
`edit_change(changeName: string, addSpecIds?: string[], removeSpecIds?: string[])`
Updates change scope. Use workspace-qualified IDs (e.g. default:auth/login). Affected artifacts may move to pending-review.

### list_specs (artifacts)
Catalog existing specs with id, title, and purpose.
`list_specs(workspace?: string)`
Lists existing spec IDs so edit_change and discovery can target real contracts. Not metered as a next turn.

### validate_artifact (artifacts)
Validate written artifacts so they can leave in-progress.
`validate_artifact(changeName: string, artifactId?: string, specPath?: string)`
Runs schema validation so artifacts can formally exit in-progress and unblock ready.

### transition (lifecycle)
Request a lifecycle transition.
`transition(changeName: string, target: string)`
Evaluates schema DAG prerequisites and required human gates. Invalid targets are rejected remotely with a server error.

### graph_search (graph)
Search the project code graph.
`graph_search(query: string)`
Queries the AST symbol index for definitions, references, and signatures across TypeScript, JavaScript, Go, Python, and PHP.

### impact (graph)
Impact analysis for a symbol or file.
`impact(symbol?: string, file?: string)`
Calculates downstream blast radius, dependents, and high-risk hotspots with bounded evidence.

### graph_reindex (graph)
Enqueue git fetch + graph index when the server index is stale.
`graph_reindex()`
Queues fetch and index jobs on the control plane so graph_search and impact reflect the latest committed tree.

### record_scenario (governance)
Record pass/fail/waived evidence for verify checklist items.
`record_scenario(changeName: string, scenarioId: string, result: "pass" | "fail" | "waived", evidence: string)`
Attaches structured evidence to a WHEN/THEN scenario during verifying.

### approve_spec (governance)
Record spec approval when the spec gate is enabled.
`approve_spec(changeName: string, reason: string)`
Records identity and a hash of the artifacts at approval time. If those artifacts change afterward, approval is cleared.

### approve_signoff (governance)
Record signoff when the signoff gate is enabled.
`approve_signoff(changeName: string, reason: string)`
Certifies verified implementation before archive into the permanent living spec tree.


Last updated: 2026-10-13