{
  "id": "axiomao:operating-an-organization",
  "edition": "0.1",
  "language": "en",
  "status": "implementation",
  "title": "Operating an organization",
  "description": "Monitor unfinished responsibilities, send durable requests and recover before resuming work.",
  "canonical": "https://axiomao.org/en/operating-an-organization/",
  "published": "2026-10-14",
  "sections": [
    {
      "id": "orientation",
      "heading": "Inspect the operating contour",
      "paragraphs": [
        "Before acting, identify the instance, source revision, client version, active manager and launcher. Read the current mandate and pending obligations. The following diagnostic commands belong in the intended instance directory; they do not establish that a native model or service is available. If a service already owns management, a second interactive session should send a request rather than seize control. Local process health and organizational progress are different observations."
      ],
      "code": {
        "language": "bash",
        "text": "python3 -m runtime status\npython3 -m runtime doctor"
      }
    },
    {
      "id": "requests",
      "heading": "Use a durable request channel",
      "paragraphs": [
        "AxiomAO documents an owner-message path that stores a request before a model runs. Repeating an identifier with identical content is idempotent; changed content requires a different identifier. The example is intended for an initialized instance with a manager or launcher able to handle messages. Listing replies does not itself process the request. Require the eventual response to identify the original request, and do not assume a queued message has already produced work."
      ],
      "code": {
        "language": "bash",
        "text": "python3 -m runtime message send --id local-review-1 --text \"Review the local research notes\"\npython3 -m runtime message list --to owner"
      }
    },
    {
      "id": "routine",
      "heading": "Watch unresolved work and resource use",
      "paragraphs": [
        "An operating review should cover overdue commitments, unacknowledged batches, unknown actions, running agents, permission changes and resource consumption. Compare movement in these records with actual accepted outputs. Repeated activity can hide a failure to finish. Choose review intervals according to consequences and cost; a short local observation is not evidence of day-long reliability. Preserve unresolved findings with a next action, responsible actor and condition for revisiting them."
      ]
    },
    {
      "id": "maintenance",
      "heading": "Recover before upgrading or retrying",
      "paragraphs": [
        "Before changing versions, stop the intended launcher, reconcile its native processes and take a consistent backup. Check the documented schema migration and restore procedure. After a failure, inspect saved results before retrying actions with uncertain effects. AxiomAO’s local ownership mechanisms are not a distributed coordination service, and client sandbox configuration remains part of the actual operating environment. Treat source updates, client updates and container adoption as changes requiring their own bounded validation."
      ]
    }
  ],
  "references": [
    {
      "label": "Axiom AO — source documentation excerpts (2026-10-14)",
      "url": "https://axiomao.org/reference/implementation-evidence.md"
    }
  ],
  "related": [
    "https://axiomao.org/en/lifecycle-events-execution/",
    "https://axiomao.org/en/recovery-observability-audit/",
    "https://axiomao.org/en/implementation-and-validation/"
  ]
}