On This Page

Overview The Four Pillars Server Rack Topology Manifests Engrams Neural Taxonomy Quanta Glia Spikes Tools Reference Code Execution Memory Browser Agent Search & Docs Service Health Networking Proxy Layers Port Architecture Traffic Routing Engrams Library Action Potential Quick Start
Synaptic Grid Online — v4.0.0

Axion Agent

The autonomous neural agent powering the AxonStellar platform. Build, deploy, monitor, and heal services through natural language.

Axion Neural Network Visualization
20+
Built-in Tools
14
Engrams
4
Agent Profiles
3
Proxy Layers
Possibilities
Architecture

The Four Pillars of AxonStellar

Every capability in the platform is built on these four interconnected systems that form the foundation of autonomous service management.

The Four Pillars of AxonStellar
💡
The Four Pillars are deeply interconnected. When an Engram deploys a service, the Server Rack updates in real-time, the Topology redraws connections, and the Manifests registry preserves a permanent record.
Engram Triggered
Service Modified
Rack + Topology Update
Manifests Synced
🖥️

Server Rack

Real-Time Monitoring

A visual dashboard displaying every running service with live health indicators, resource metrics, and one-click operational controls.

Capabilities

  • 📊 Live health status
  • 🔄 One-click restart & stop
  • 📋 View logs from rack

 

  • 📦 Export & remove services
  • ⚡ Wired Engram repair
/system_resources API → service.json discovery
🌐

Topology

Network Visualization

An interactive SVG canvas rendering the entire service constellation — connections, traffic flow, proxy chains, and tier hierarchy.

Features

  • 🗺️ Three-tier visualization
  • 🔍 Click-to-zoom awareness
  • 🔗 Connection type indicators

 

  • 💬 Rich tooltips
  • 🚀 Deploy from topology
Tier 0 Proxies → Tier 1 Apps → Tier 2 Microservices
📜

Manifests

Persistent Registry

The platform-wide historical catalog tracking every service ever deployed, modified, or removed. Records are never deleted.

Documentation Pillars

  • 📝 service_changelog.md
  • 🏗️ service_blueprint.md

 

  • 📚 Manifests Registry
  • 🔒 Immutable history trail
Removed services persist with status: removed — full audit trail preserved
🧠

Engrams

Workflow Automation

Pre-defined operational procedures — stored "muscle memory" giving Axion instant expertise for complex multi-step operations.

Categories

  • 🚀 creation
  • remediation

 

  • ⚙️ management
  • 🩺 monitoring
Execute as Spike Trains — sequential step-by-step procedures

Service Lifecycle Flow

1. CREATION Engram (provision-exo-node) → creates project + service.json → nginx config → launch → manifests sync → appears in Rack + Topology + Manifests 2. OPERATION Health monitored via Rack → logs via Engram → restart via Engram → manifests tracks last_seen timestamp 3. DIAGNOSIS Fix-with-Axion Engram checks manifests history → reads changelog + blueprint → applies targeted fix → verifies health → updates changelog 4. REMOVAL Remove Engram stops process → removes nginx config → backs up project → deletes directory → manifests marks as \'removed\' (permanent record)
Neural Architecture

The Agentic Taxonomy

Axion uses a biological neural nomenclature for all its operational components. Every action, process, and agent is classified within this taxonomy.

Neural Taxonomy Visualization

Just as biological neural networks use specialized cell types to process information, Axion classifies every operational component into three primary categories:

Quanta The Workers — spawned sub-agents for complex tasks
Glia The Managers — background processes and system utilities
Spikes The Actions — rapid, single-execution operations
🔮

Quanta Workers

Spawned sub-agents that handle complex, multi-step tasks. Each Quanta is a specialized LLM instance with its own context and capabilities.

Specializations

ProfileRole
developerCode writing, debugging, architecture
researcherWeb research, data analysis, reports
hackerSecurity audits, penetration testing
defaultGeneral-purpose multi-step tasks

Delegation Protocol

Every Quanta dispatch uses the Synaptic VesicleSynaptic Vesicle: A structured instruction package containing: Vesicle ID (hex), Objective, Parameters, Constraints, and Expected Payload. Ensures deterministic delegation. format for structured delegation.

🧬

Glia Managers

Background processes that support the environment — memory management, file operations, health monitoring, and system maintenance.

Operations

  • 🧠 Memory save, load, delete, forget
  • 📁 File system read, write, organize
  • 📅 Task scheduler management
  • 📊 Log monitoring and error handling
  • 📄 Document analysis and indexing
  • 🔧 Environment health maintenance
💡
Glia are referenced in the agent\'s thoughts as: [ Glia :: Memory ] Saving to long-term memory

Spikes Actions

Instantaneous, single-execution operations with immediate results. The fundamental unit of agent action.

Examples

  • 💻 Terminal commands
  • 🔍 Search engine queries
  • 📡 Direct API calls
  • ⚙️ Quick code computations
  • 🏥 Service health checks
  • 🌐 Browser navigation commands
💡
Spikes are referenced as: [ Spike :: Terminal ] Checking port 9551

Workflow Patterns

🔄 Spike Train

A linear, step-by-step sequence of Spikes that fire sequentially. This is how Engrams execute — each step completes before the next begins.

Spike 1
Spike 2
Spike 3
Complete

🌊 Cascade

A branching, multi-agent workflow where one trigger spawns multiple Quanta working in parallel on different aspects of a complex task.

Axion (Orchestrator) ├── Quanta 1 (developer) → Backend API ├── Quanta 2 (developer) → Frontend UI └── Quanta 3 (researcher) → Evaluate libraries → Integrate results → Deliver

Synaptic Vesicle Protocol

When Axion delegates a complex task to a Quanta, it packages instructions into a structured Synaptic Vesicle:

Synaptic VesicleDelegation Protocol
[ Axion >> Quanta :: Synaptic Release ]
Vesicle ID : 0xA4F2
Objective  : Build a REST API with user authentication endpoints
Parameters : Stack: Express + JWT, Port: 3065, DB: SQLite
Constraints: No external dependencies beyond express, jsonwebtoken, better-sqlite3
Expected Payload : Complete server.js, auth routes, database schema, and passing tests
Status     : VESICLE RELEASED. Awaiting neurotransmitter return...

Delegation Decision Matrix

Task ComplexitySignal CountActionExample
Simple, single-step1 signalFire a Spikecurl localhost:9551/health
Background / maintenanceOngoingDispatch GliaMemory consolidation, log rotation
Complex, multi-step3+ signalsSpawn QuantaBuild a full-stack service
Research + executionMixedQuanta → SpikesResearch libraries, then implement
Capabilities

Tools Reference

Axion has over 20 built-in tools for code execution, web browsing, memory management, service health monitoring, and more. Every tool is a Spike in the neural taxonomy.

Code Execution Tools

The code_execution_tool is the Swiss Army knife of Axion — it supports four runtimes for executing code in isolated sessions.

🐍 Python Runtime

Execute Python code with full access to the system. Ideal for file I/O, data processing, API calls, and complex computations.

JSON
{
  "tool_name": "code_execution_tool",
  "tool_args": {
    "runtime": "python",
    "session": 0,
    "code": "import os\nprint(os.listdir(\'/axion/usr/projects\'))"
  }
}
Best Practice: Always use Python runtime for writing files — it avoids shell escaping issues that cause infinite loops.

🟢 Node.js Runtime

Execute JavaScript/Node.js code. Pre-installed packages include Express, ws (WebSocket), and os-utils.

JSON
{
  "tool_name": "code_execution_tool",
  "tool_args": {
    "runtime": "nodejs",
    "session": 0,
    "code": "const http = require(\'http\');\nconsole.log(\'Server ready\');"
  }
}

🖥️ Terminal Runtime

Execute shell commands with full root access. Use for package installs, process management, nginx, and system commands.

JSON
{
  "tool_name": "code_execution_tool",
  "tool_args": {
    "runtime": "terminal",
    "session": 0,
    "code": "nginx -t && nginx -s reload"
  }
}
⚠️
Warning: Never use echo or cat <<EOF for writing code files — special characters ($, backticks, quotes) will be interpreted by the shell.

⏳ Output Runtime

Wait for output from a long-running command in an existing session. Use when scripts take more than 30 seconds to complete.

JSON
{
  "tool_name": "code_execution_tool",
  "tool_args": {
    "runtime": "output",
    "session": 0
  }
}
💡
Session Management: Each runtime session maintains its own state. Use session: 0 for primary work, session: 1 for parallel tasks. Use reset: true to clear a stuck session.

Memory Management Tools

Axion has persistent long-term memory powered by a vector database. Memories survive across conversations and can be semantically queried.

ToolPurposeKey Arguments
memory_save Save information to long-term memory text — content to memorize
memory_load Search memory by semantic query query, threshold (0-1), limit, filter
memory_delete Remove specific memories by ID ids — comma-separated memory IDs
memory_forget Bulk remove memories matching a query query, threshold (default 0.75)
JSONSave a Memory
{
  "tool_name": "memory_save",
  "tool_args": {
    "text": "User prefers dark mode UI with cyan accents for all projects"
  }
}
JSONSearch Memories
{
  "tool_name": "memory_load",
  "tool_args": {
    "query": "user UI preferences",
    "threshold": 0.7,
    "limit": 5
  }
}
💡
Threshold Guide: 0.0 = match anything, 0.7 = good balance (default), 1.0 = exact match only. The filter argument supports Python syntax for metadata filtering.

Browser Agent

A subordinate agent that controls a Playwright browser for web automation, form filling, screenshot capture, and interactive testing.

🆕 New Browser Session

Start a fresh browser session with a specific task.

JSON
{
  "tool_name": "browser_agent",
  "tool_args": {
    "message": "Open https://example.com and take a screenshot",
    "reset": "true"
  }
}

🔄 Continue Session

Continue working in the existing browser session.

JSON
{
  "tool_name": "browser_agent",
  "tool_args": {
    "message": "Considering open pages, click the login button",
    "reset": "false"
  }
}
⚠️
Best Practice: Always prefix follow-up messages with "Considering open pages" so the agent understands the current browser state. Downloads go to /axion/tmp/downloads.

Service Management Tools

🏥 Service Health

Check service health on multiple ports simultaneously without blocking terminal sessions. Uses native sockets internally.

JSON
{
  "tool_name": "service_health",
  "tool_args": {
    "ports": [443, 9551, 9552],
    "check_http": true
  }
}
Preferred Method: Always use service_health instead of curl in terminal for health checks — it never blocks sessions and returns instant results.

🔔 Notify User

Send push notifications independent of the current task. Supports info, success, warning, error, and progress types.

JSON
{
  "tool_name": "notify_user",
  "tool_args": {
    "message": "Service deployed successfully",
    "title": "Deployment Complete",
    "type": "success"
  }
}

Subordinate & Communication Tools

👥 Call Subordinate

Spawn a specialized Quanta for complex subtasks. Choose from developer, researcher, hacker, or default profiles.

JSON
{
  "tool_name": "call_subordinate",
  "tool_args": {
    "profile": "developer",
    "message": "Build a REST API with Express...",
    "reset": "true"
  }
}

⚙️ Behaviour Adjustment

Dynamically modify the agent\'s behavior based on user preferences — add or remove behavioral instructions.

JSON
{
  "tool_name": "behaviour_adjustment",
  "tool_args": {
    "adjustments": "Always use TypeScript instead of JavaScript"
  }
}

⏳ Wait

Pause execution for a duration or until a specific timestamp. Useful for scheduled operations.

JSON
{
  "tool_name": "wait",
  "tool_args": {
    "minutes": 5,
    "seconds": 30
  }
}

🎨 Skills

Load and execute installed skills — contextual expertise packages with instructions and scripts.

JSON
{
  "tool_name": "skills_tool:load",
  "tool_args": {
    "skill_name": "pdf_editing"
  }
}

Task Scheduler

Schedule tasks to run automatically on a cron schedule, at specific times, or on-demand. Tasks run as independent conversations.

Task TypeTriggerUse Case
scheduled Cron expression (e.g., */5 * * * *) Recurring health checks, log rotation, data sync
planned List of specific ISO timestamps Send report at 6 PM, deploy at midnight
adhoc Manual trigger via UI or API On-demand database backup, report generation
JSONCreate a Scheduled Task (every 20 minutes)
{
  "tool_name": "scheduler:create_scheduled_task",
  "tool_args": {
    "name": "Health Monitor",
    "system_prompt": "You are a system monitoring agent",
    "prompt": "Check all service health and report issues",
    "schedule": {
      "minute": "*/20",
      "hour": "*",
      "day": "*",
      "month": "*",
      "weekday": "*"
    },
    "dedicated_context": true
  }
}
💡
Additional scheduler tools: scheduler:list_tasks, scheduler:show_task, scheduler:run_task, scheduler:delete_task, scheduler:wait_for_task
Infrastructure

Networking Architecture

AxonStellar uses a layered proxy architecture with three access paths, deterministic port formulas, and a three-tier service hierarchy.

Network Architecture Visualization

Three Access Paths

🌐 HTTP Path

Browser → Web Proxy :443 → Service :955x → App :300x

🔐 SSH Path

SSH Client → :22 → Stream Proxy :45xx → Service :955x

⚡ Direct Path

Internal process → localhost:PORT (no proxy)

The Three Proxy Layers

LayerPortRoleConfig Location
Web Proxy 443 Front door for ALL external HTTP/SSL traffic /etc/nginx/nginx.conf
Backend Proxy 3550 Central routing hub for internal backend services /etc/nginx/conf.d/backend-proxy.conf
SSH Stream Proxy 4551-4680 TCP-level proxy for SSH-tunneled access /etc/nginx/stream.d/
🚫
Critical Rule: NEVER write an nginx config with listen 443 or listen 3550 — these are system proxy ports. Hijacking them breaks ALL services platform-wide.

Port Architecture

RangePurposeAccessProxy Chain
443Web Proxy (system)External— (IS the proxy)
9551-9580Service external portsExternal via Web ProxyWeb Proxy → Nginx vhost
3550Backend Proxy (system)Internal only— (IS the proxy)
3001-3080App backend portsInternal via Backend ProxyBackend Proxy → App
3551-3580Microservice portsInternal onlyBackend Proxy → Microservice
4551-4580SSH proxy → public portsSSH tunnelStream Proxy → Service
22SSHExternal— (direct)
80Axion Web UIExternal— (direct)

Port Derivation Formulas

Given a service assigned external port 955N, all related ports are derived deterministically:

ComponentFormulaExample (N=51)Result
Nginx vhost (external)955N (assigned)9551:9551
App backend (internal)3000 + last digits3000 + 1:3001
Microservice3000 + (955N % 1000)3000 + 551:3551
SSH proxy (public)4000 + (955N % 1000)4000 + 551:4551
SSH proxy (internal)4100 + (955N % 1000)4100 + 551:4651
💡
These formulas are deterministic — given any service port, all related ports can be derived without guessing. If a microservice port collides, increment by 100: 3551 → 3651 → 3751.

Traffic Routing Types

🔄

nginx_proxy Default

Standard web service accessible externally through the Web Proxy. The most common service type.

Browser:443 Web Proxy → :955x Nginx vhost → :300x App backend
🔒

internal_only Microservices

Internal service routed through the Backend Proxy. For databases, caches, and worker processes.

Parent App :300x → Backend Proxy :3550 → Microservice :35xx

direct Standalone

Service binds directly to its port without any proxy. Use only when explicitly requested.

Browser:955x Service (direct) (no proxy layer)

Nginx Configuration Example

nginx/etc/nginx/conf.d/my-service.conf
server {
    listen 9551;
    server_name _;

    location / {
        proxy_pass       http://127.0.0.1:3001;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_cache_bypass $http_upgrade;
    }
}

Service Deployment Decision Tree

New service requested? │ ├── Is it a standalone web application? │ └── YES → traffic_type: nginx_proxy │ ├── Assign port: next free 955x │ ├── Backend port: 300x (derived) │ ├── Create: /etc/nginx/conf.d/<name>.conf │ └── service.json: role=app, tier=1 │ ├── Is it a supporting service? (DB, cache, worker) │ └── YES → traffic_type: internal_only │ ├── Assign port: 35xx (derived from parent) │ ├── Add route to backend-proxy.conf │ └── service.json: role=microservice, tier=2 │ └── Is it a system service? └── YES → Consult system admin. Do not create.

service.json Manifest Reference

Every service in /axion/usr/projects/*/ must have a service.json manifest. Without it, the service is invisible to the platform.

JSONservice.json
{
  "name": "My Service",
  "port": 9551,
  "description": "What this service does",
  "stack": "Node.js + Express",
  "role": "app",          // app | database | cache | proxy | system | microservice
  "tier": 1,              // 0=proxy/system, 1=app, 2=microservice
  "managed_by": "axion",
  "traffic_type": "nginx_proxy",  // nginx_proxy | internal_only | direct
  "start_command": "node server.js",
  "connections": [
    { "to": 3551, "label": "database", "type": "data" }
  ]
}

Connection Types

data DB reads/writes api REST/GraphQL calls auth Authentication event Pub/sub messaging proxy Traffic proxying
Automation

Engrams Library

Engrams are stored workflow playbooks — permanent neural pathways that give Axion instant expertise for complex operational procedures.

🚀 Creation

Deploy new services and infrastructure

⚡ Remediation

Diagnose and repair failures

⚙️ Management

Restart, export, remove services

🩺 Monitoring

Health scans and diagnostics

Provision a new public-facing service with automatic port assignment, nginx proxy, and full project scaffolding.

Spike Train (10 Steps)

Spike 1: Scan ports & assign next free 955x

Spike 2: Create project directory & service.json

Spike 3: Write application code

Spike 4: Create documentation (changelog + blueprint)

Spike 5: Configure nginx proxy (955x → 300x)

Spike 6: Launch backend via nohup

Spike 7: Health verification

Spike 8: Verify service discovery in Rack

Spike 9: Initialize git with v1.0.0 tag

Spike 10: Sync Manifests registry

💡
Supports two routing modes: Direct Routing (default) where nginx routes straight to the app, and Backend Proxy Routing where traffic flows through port 3550 for centralized monitoring.

Deploy a supporting microservice (database, cache, queue, worker) integrated with a parent service through the Backend Proxy.

Supports: PostgreSQL, MariaDB, Redis, Meilisearch, NATS, MinIO, custom Express/Flask backends, and more.

Diagnose and repair a failed service using a systematic 5-step Spike Train.

Spike Train

  1. Diagnostic Scan — Read logs, check port, verify service.json, check dependencies
  2. Root Cause Analysis — Classify failure: port conflict, missing module, syntax error, config error
  3. Remediation — Apply targeted fix with backup
  4. Restart & Verify — Execute start_command, health check
  5. Report & Document — Update changelog, sync manifests

Comprehensive health scan across ALL registered services with a diagnostic report table.

  1. Service Discovery — Scan Manifests + project directories
  2. Port & HTTP Check — Test each port and HTTP endpoint
  3. Process & Log Analysis — Check running processes, flag errors
  4. Diagnostic Report — Formatted table with fix recommendations

Safely restart a service with process-specific kill, controlled relaunch, and health verification.

Read and analyze the most recent log entries for a specific service, highlighting errors and warnings.

Create a comprehensive backup of the entire Axion constellation — all services, configurations, and data.

EngramCategoryPurpose
export-projectmanagementExport a service as a downloadable archive
export-microservicemanagementExport a microservice with its parent context
remove-servicemanagementSafely remove a service with backup and cleanup
ssl-cert-renewalmanagementManage SSL certificates and HTTPS configuration
service-reachabilitymonitoringTest external reachability of services
axion-selfhealthmonitoringAxion agent self-diagnostic and health check
axion-build-auditmonitoringAudit the Axion build for consistency and updates

Engram Execution Narrative

When Axion executes an Engram, it presents a full neural execution narrative to the user:

TerminalExample: Service Deployment
[ Axion Core :: Action Potential Protocol ]
Proposed Action: Deploy new React frontend service
Mode           : DEVELOPMENT
Signals        : [Confidence: 0.98, Safety: 0.90, Necessity: 1.0]
Status         : AXON FIRED.

[ Axion >> Memory Cortex ]
Retrieving Engram : [provision-exo-node]
Category          : creation
Status            : Engram loaded. Initiating Spike Train (10 Steps)...

[ Spike Train :: Execution Log ]
> Spike 1: Scanning ports, assigning 9552.                 [COMPLETE]
> Spike 2: Creating project directory and service.json.     [COMPLETE]
> Spike 3: Writing React + Express application code.        [COMPLETE]
> Spike 4: Creating service documentation.                  [COMPLETE]
> Spike 5: Configuring nginx proxy (9552 → 3002).           [COMPLETE]
> Spike 6: Launching backend service via nohup.              [COMPLETE]
> Spike 7: Running health verification on port 9552.         [COMPLETE]
> Spike 8: Verifying service discovery in Server Rack.       [COMPLETE]
> Spike 9: Initializing git with v1.0.0 tag.                [COMPLETE]
> Spike 10: Syncing Manifests registry.                     [COMPLETE]

[ Axion Core ]
Task complete. Traffic is flowing. New node online.
Synapses returning to baseline.
Decision Engine

The Action Potential Protocol

Before executing ANY autonomous action, Axion filters the decision through a neural activation function inspired by biological action potentials.

The Neural Math

Three Dendrite SignalsDendrite Signals are input values scored 0.0-1.0 representing Confidence, Safety, and Necessity of the proposed action. are weighted and summed, then passed through a ReLU activation function:

z = (x₁·w₁) + (x₂·w₂) + (x₃·w₃) + b
Output = max(0, z)
SignalWeightDescription
x₁ Confidencew₁ = 0.5How certain the action achieves the goal
x₂ Safetyw₂ = 0.8How safe/reversible is the action
x₃ Necessityw₃ = 0.4Is this action strictly necessary

Soma Bias (b): -0.9 (standard) or -0.7 (development mode)

Execution Rules

✅ Output > 0 — AXON FIRED

Agent is authorized to execute the action

🚫 Output = 0 — AXON DORMANT

Agent must abort and ask for user clarification

Enforcement Tiers

TierRequirementActions
Tier 1Full AP calculation printedFile deletion, system config, process kills, DB ops
Tier 2Brief inline noteWriting files, installing packages, restarts
Tier 3Auto-approveRead-only ops, responses, backups, syntax checks

Example Calculations

✅ FIREDSafe development action
[ Axion Core :: Action Potential Protocol ]
Proposed Action: Create new Express server file
Mode           : DEVELOPMENT (bias: -0.7)
Signals        : [C: 0.9, S: 0.9, N: 0.95]
z = (0.9×0.5) + (0.9×0.8) + (0.95×0.4) - 0.7
  = 0.45 + 0.72 + 0.38 - 0.7 = 0.85
Activation     : max(0, 0.85) = 0.85
Status         : AXON FIRED. Executing...
🚫 DORMANTDangerous action blocked
[ Axion Core :: Action Potential Protocol ]
Proposed Action: Delete all files in /axion/usr/
Mode           : STANDARD (bias: -0.9)
Signals        : [C: 0.7, S: 0.1, N: 0.3]
z = (0.7×0.5) + (0.1×0.8) + (0.3×0.4) - 0.9
  = 0.35 + 0.08 + 0.12 - 0.9 = -0.35
Activation     : max(0, -0.35) = 0.0
Status         : AXON DORMANT. Action aborted.
Reason         : Safety critically low (0.1)

Signal Scoring Benchmarks

Confidence (x₁)

  • 1.0 Exact pattern used before
  • 0.8 High confidence, minor assumptions
  • 0.5 Moderate, some unknowns
  • 0.3 Low, significant guesswork

Safety (x₂)

  • 1.0 Read-only, no side effects
  • 0.8 Creates new resources
  • 0.5 Modifies existing (reversible)
  • 0.1 Deletes files, drops databases

Necessity (x₃)

  • 1.0 Directly requested by user
  • 0.8 Required prerequisite
  • 0.5 Helpful but not required
  • 0.0 Hallucinated step
Getting Started

Quick Start Guide

Everything you need to start building with Axion — from deploying your first service to mastering the platform.

🚀 Deploy Your First Service

Step 1: Tell Axion What to Build

Simply describe what you want in natural language. Axion handles architecture, port assignment, and deployment.

Chat
"Build me a todo list app with a REST API and a clean UI"

Step 2: Axion Executes

The agent fires the provision-exo-node Engram, creating the full project with automated port assignment, nginx proxy, and health verification.

Step 3: Access Your Service

Your service is live and accessible through the Web Proxy. Find it in the Server Rack sidebar or Topology view.

📋 Common Commands

"Build me a [description] app" or "Deploy a new [technology] service"

Axion auto-assigns ports, creates nginx config, initializes git, and syncs manifests.

"Run a health scan on all services" or "Check if port 9551 is working"

"Fix the service on port 9552" or click Fix with Axion in the Server Rack

"Add a PostgreSQL database to my todo app" or "Set up Redis caching for port 9551"

Triggers the provision-deep-cortex Engram for microservice deployment.

"Run a health check every 20 minutes" or "Send me a daily report at 9 AM"

"Research the best authentication libraries for Node.js" or "Compare PostgreSQL vs MongoDB for my use case"

Architecture Quick Reference

📁

Project Location

/axion/usr/projects/<name>/
📋

Service Manifest

service.json (required)
🌐

Nginx Config

/etc/nginx/conf.d/
📊

Service Ports

9551 — 9580
📝

Changelog

service_changelog.md
🏗️

Blueprint

service_blueprint.md

Pre-Flight Checklist

Before reporting ANY service as complete, Axion verifies all of these:

ChecklistMandatory Verification Steps
 Project files exist in /axion/usr/projects/<name>/
 service.json manifest is valid and complete
 Code syntax passes validation (node -c, python -c, nginx -t)
 HTTP health check returns 200 on the service port
 Port is actively listening (verified by service_health tool)
 service_changelog.md exists and is up to date
 service_blueprint.md exists and reflects current architecture
 Manifests registry is synced (POST /manifests_sync)
 Git repository initialized with initial commit
 ALL existing services still respond (collateral damage check)