# Versioning, maturity and roadmap

The whole target system is shown and then opened product by product, capability by capability: design, implementation, availability and authority are recorded as four separate states; the roadmap advances on exit evidence; the architecture map itself is not an authorization to launch or to switch baselines.

> Document ID: MYRILUM-DOC-ARCH-030
> Document type: concept
> Product: NOT_APPLICABLE
> Version: 0.1.0
> Region: GLOBAL
> Visibility: PUBLIC
> Publication: PUBLISHED_GLOBAL
> Content maturity: DRAFTED
> Governance: APPROVED
> Capability state: IN_DEVELOPMENT
> Availability: NOT_AVAILABLE
> Authorization: PUBLIC_INFORMATION
> Freshness: CURRENT
> Safety class: INFORMATIONAL
> Owner: Web3Capital Documentation Steward
> Approvers (assignment only; not approval evidence): Stephen
> Canonical authority: SRC-ARCHITECTURE-ATLAS-V2-2
> Source commit: 6b41cce4496de03c67a501aa94cd41ec6ac0e85a
> Content digest: ed364534bc48093477c94fe9f395375cdae752ef5a101895fb17c765939b4247
> Effective: NOT_SET
> Expires: NOT_SET
> Last verified: 2026-09-23
> Review due: 2026-10-23
> Command authority: NONE
> Canonical URL: /en/architecture/versioning-and-roadmap

<a id="overview"></a>

## What this page covers

This is MYRILUM's target architecture. It does not mean everything on the map is live; whether a capability can be used today is stated in “Current availability”.

A complete system, available in stages, approved item by item, driven by evidence. This page states principles only; implementation details are not published.

<a id="four-axes"></a>

## Four states, recorded separately

Every capability records four states separately: how far the design decision has gone; how far implementation and verification have gone; who can use it (internal, preview, invited, generally available); and whether specific actions such as production, payments, sending data out or regions are authorized. One state moving forward does not move the others.

<a id="everything-versioned"></a>

## Every key object is versioned

Product and sales contracts, agents, skills and model policies, data, evidence and results, and interfaces, policies and release artifacts all carry versions; results cite specific versions, and a correction adds a new version instead of overwriting the old one.

<a id="roadmap-by-evidence"></a>

## The roadmap advances on exit evidence

The roadmap moves in stages, and each stage ends with exit evidence that can be verified; if the evidence does not hold, the next stage does not start. The order of opening is to make the platform's own delivery and commercial loop solid first, then widen to an invited ecosystem and enterprises, and only then open up in a controlled way. Unapproved dates are not published.

<a id="change-becomes-baseline"></a>

## How a change becomes the new baseline

A change states why it is made, what it changes and how it affects data and rights; it first resolves conflicts with existing naming, ownership of responsibilities, authorization, commercial arrangements and domains; it is then explicitly approved by someone with authority — reading on does not count as approval; once approved it is activated and recorded on its own, changing the source of truth and the references that point to it while the old version is kept. Going into production is a separate release process. A candidate version never overwrites frozen historical records.

<a id="source"></a>

## Source

This page follows A30 of the MYRILUM architecture map v2.2. Under the public boundary it publishes principles only and carries no diagram. Related: “MYRILUM platform architecture overview”; “Business domains and fact authority”; “Engineering and controlled self-evolution”.

---

This document is read-only, grants no command authority, and does not authorize deployment, payment, provider modification, or any other real-world action.