# Engineering and controlled self-evolution

MYRILUM may use AI to build MYRILUM, but the rights to run customer work, to implement, to review and to release stay separate; every upgrade goes the same way: observe → specify → build → verify → human approval → release → measure.

> Document ID: MYRILUM-DOC-ARCH-029
> 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: 468dce44addd6993266b165268802fbc9f3386b1cad7a22420ceed354fcd456c
> Effective: NOT_SET
> Expires: NOT_SET
> Last verified: 2026-09-23
> Review due: 2026-10-23
> Command authority: NONE
> Canonical URL: /en/architecture/engineering-and-evolution

<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”.

An upgrade never bypasses the same governance as day-to-day operation. This page states principles only; implementation details are not published.

<a id="separated-rights"></a>

## Four rights kept apart

Running customer work, implementing a change, reviewing it and approving its release are four different rights. An agent that implements a change can never approve its own high-impact result, nor change funds, permissions or governance policy on its own.

<a id="one-path"></a>

## Every upgrade follows one path

Work starts from real failures, user needs, and cost and quality evidence, and states the problem, the options, goals and non-goals, the scope of impact, the tests and how to roll back. With a scoped authorization it is built in a restricted environment, and repeatable tests cover normal, failure and security cases. Before release a person approves one specific artifact and environment; after release the effect is observed and rolled back if it falls short, and irreversible actions are handled on their own.

<a id="review-independence"></a>

## Review is judged by independence, not headcount

Different roles, models or scripts can still share the same mistake. Review is judged by whether its sources are truly independent, not by adding more participants.

<a id="pipeline-isolated"></a>

## The engineering pipeline is isolated from customer data

The engineering pipeline never inherits access to customer data, and customer tool runs never touch the main production release credentials.

<a id="evidence-bound"></a>

## “Tested” means the test can be found

Release is never justified by word of mouth: evidence is bound to the actual version and environment, and “tested” must point to the matching tests and results. An upgrade can never change goals, permissions or core policies set by people on its own; changing them goes back through specification and approval.

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

## Source

This page follows A29 of the MYRILUM architecture map v2.2. Under the public boundary it publishes principles only and carries no diagram. Related: “Governance, operations and run boundaries”; “Observability, quality, cost and operations”; “Versioning, maturity and roadmap”.

---

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