Axodus Product and Nucleus Map

●Draft

Axodus nuclei are bounded responsibility domains. A nucleus may define a product, an operational capability, a control surface, or shared infrastructure. Inclusion in this map does not prove production availability.

Nucleus	Primary Responsibility	Canonical Output	Main Dependencies	Current Public Posture
Governance	Constitutional, policy, approval, escalation, and accountability decisions	Valid decision or authorization record	Participants, owners, executors, Accountability	Governed model; active authority varies by scope
Business	Transform demand into plans, deliveries, services, infrastructure, and assets	Qualified request, project, delivery, or reusable asset	Governance, Runtime, ACS/Trinity, product owners	Consolidated mock/read-only prototype
Runtime	Track state, handoffs, validation, blockers, incidents, and receipts	Lifecycle transition or operational record	Every participating nucleus	Canonical model; production runtime unverified
Academy	Education, assessment, onboarding, and Proof of Knowledge	Learning or scoped qualification evidence	Governance, Marketplace, Tokenomics when authorized	Product intent and partial implementation
Marketplace	Distribute, list, or license authorized assets and services	Listing, offer, license, or distribution record	Business, owners, Governance, Treasury	Product model/prototype; settlement unverified
ACS	Analysis, policy checks, alerts, risk signals, and guarded assistance	Recommendation, alert, local hold, or receipt	Runtime, owners, Governance/Security	Non-production, default-deny prototype
Treasury	Govern authorized custody, reserves, allocation, movement, and reporting	Financial decision or movement record	Governance, Security, product owners	Governed design; active execution unverified
Tokenomics	Define utility, issuance constraints, eligibility, and distribution rules	Approved token or utility rule	Treasury, Governance, Academy, contracts	Directional and partial prototype
Trading	Trading research, risk controls, and authorized strategy products	Research, risk record, or authorized result	Treasury, ACS, providers, Governance	Prototype; financial gates closed
Mining	Mining infrastructure, participation, telemetry, economics, and risk	Feasibility, telemetry, or authorized operation record	Treasury, ACS, providers, Governance	Prototype; ownership and operation incomplete
Lottery	Draw, randomness, eligibility, claims, and protection models	Prototype draw or claim record	Legal, Governance, Treasury, Security	Prototype-only; public release blocked
DeFi	Governed decentralized-finance products and service models	Product design or authorized interaction	Treasury, Tokenomics, Security	Architecture/prototype; financial gates closed
DEX	Swap, routing, liquidity, listing, and execution-risk models	Quote, route, listing, or authorized transaction	Providers, Treasury, Security, Governance	Prototype; activation unverified
BBA	Positioning, communication, campaign, and claim-review support	Public-safe narrative or campaign artifact	Business, product owners, Governance	Documentation and service model
Accountability	Preserve decisions, releases, incidents, reports, and receipts	Reviewable evidence record	All nuclei	Governed documentation surface
Security	Define controls, security review, incidents, and disclosure	Security decision, finding, or incident record	All sensitive surfaces	Cross-cutting control surface

How the Map Works

Requests and participation enter through Business, Academy, Governance, Marketplace, or a product interface. Business or the owning nucleus establishes context. Trinity and ACS may assist. The responsible authority decides. Runtime tracks the transition. A product or implementation surface acts only when its technical and authority gates are open. Accountability preserves the result.

See Cross-Core Architecture and Execution Model for the interfaces and full flows.

Reading The Map

Each nucleus is read through four questions: what request it accepts, what bounded responsibility it owns, what output it can prepare, and what authority or evidence is still required. Coordination cores may structure work without executing product or financial actions. Product cores may define functional models without being active services. Control cores may observe or advise without autonomous authority.

A cross-reference indicates documentary dependency, not live integration. Current availability must be established on the destination page and supported by the applicable implementation, authority, activation, and evidence context.