# Governance, operations and run boundaries

Customer execution, staff operations, engineering production and external services sit in different trust boundaries; governance runs through every platform rather than being a security module added at the end.

> Document ID: MYRILUM-DOC-ARCH-008
> Document type: concept
> Product: NOT_APPLICABLE
> Version: 0.1.0
> Region: GLOBAL
> Visibility: PUBLIC
> Publication: PUBLISHED_GLOBAL
> Content maturity: VALIDATED
> 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: 882487dec08bc4ca204510e166217478fa8f68ec
> Content digest: ad5908b6e15de3af9f9faa922075b77390cb4714e1788aaefc66cf81d5f370c8
> Effective: NOT_SET
> Expires: NOT_SET
> Last verified: 2026-09-23
> Review due: 2026-10-23
> Command authority: NONE
> Canonical URL: /en/architecture/governance-and-operations

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

Customer execution, staff operations, engineering production and external services belong to different trust boundaries. Governance runs through every platform instead of sitting at the bottom as a “security module”. This page states principles only; implementation details are not published.

<a id="people-decide"></a>

## People decide; rules are public

Goals, budgets, risk tolerance and major decisions always rest with people. The principles for rules, privacy, verification, disputes and appeals are public; whoever carries out the rules does only what it is authorized to do and never quietly rewrites the record.

<a id="permissions-not-menus"></a>

## Permissions are not menus

Hiding a button does not block the back end. Databases, files, caches, indexes, queues and logs each need their own isolation.

<a id="self-improvement-bounded"></a>

## Building itself is not unlimited autonomy

MYRILUM can propose and build upgrade candidates, but whoever does the work does not thereby gain the power to release to production or change the rules. Updating models, agents and products never widens anyone's own permissions.

<a id="layers-not-deployments"></a>

## Layers are not deployments

The number of platform domains does not decide the number of databases or services. Whether and how to split depends on load, security, region and release boundaries. Customers, staff, durable execution and engineering production each run inside their own boundary.

<a id="metrics-protect-value"></a>

## Metrics protect user value

The first thing watched is effective delivery within authorization and budget, alongside revisions, cost, retention and risk. When an incident happens, impact is contained and service restored first, then people are notified and the incident reviewed; every change and release is bound to a specification, evidence, approval and version.

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

## Source

This page follows A08 of the MYRILUM architecture map v2.2. Under the public boundary it publishes principles only and carries no diagram.

---

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