[ Organization implementation · browser local ]

Turn an AI ambition into an accountable operating sequence.

The Architecture Readiness Assessment maps six practical AI operating domains: data paths, device fleet, model lifecycle, identity and access, outage fallback, and accountability. It turns the stated evidence into a gap register and a bounded implementation sequence.

[ What it does ]

Structures a self-reported inventory, makes missing evidence visible, and orders the next operational work.

[ What it exports ]

A portable gap register and implementation sequence for an accountable owner to review.

[ What it does not do ]

It does not inspect systems, verify controls, certify security or privacy, or authorize production use.

[ 01 · establish scope ]

Assessment or implementation nameWorkload and intended boundaryAccountable implementation owner

[ 02 · record stated evidence ]

Select the evidence status you can support today. “Documented & tested” means the organization has a current, reviewable record and has tested the applicable behavior; it is not independently verified by this tool.

Data paths

Describe inputs, outputs, device storage, telemetry, logs, sync, remote transfers, retention, deletion, and authorized processors.

Evidence status

Notes or evidence reference

Device fleet

Describe supported devices, OS versions, memory/storage, acceleration, connectivity, accessibility needs, and excluded devices.

Evidence status

Notes or evidence reference

Model lifecycle

Describe model/runtimes, source, versioning, update approval, rollback, evaluation cases, and monitoring or review after change.

Evidence status

Notes or evidence reference

Identity & access

Describe who can use, administer, change, view, export, or connect the system; include service accounts and third parties.

Evidence status

Notes or evidence reference

Outage fallback

Describe behavior when the device, network, provider, model runtime, authentication, or integration fails.

Evidence status

Notes or evidence reference

Accountability

Describe the decision owner, output reviewer, incident or exception owner, success measures, stop conditions, and review cadence.

Evidence status

Notes or evidence reference

[ 03 · readiness output ]

Gap register

6 gaps require an accountable response before treating the operating design as evidenced.

Data paths

High · Not assessed

No readiness evidence has been recorded for data paths.

Next action: Map the end-to-end data path and approve what may move, be retained, or be logged.

Device fleet

High · Not assessed

No readiness evidence has been recorded for device fleet.

Next action: Set the supported fleet and test the least capable device under representative conditions.

Model lifecycle

High · Not assessed

No readiness evidence has been recorded for model lifecycle.

Next action: Define a version, evaluation, update, and rollback process before scaling the feature.

Identity & access

High · Not assessed

No readiness evidence has been recorded for identity & access.

Next action: Assign access roles, approval paths, and offboarding/review responsibilities for the intended workflow.

Outage fallback

High · Not assessed

No readiness evidence has been recorded for outage fallback.

Next action: Specify a user-visible fallback, timeout, recovery path, and owner for each material dependency.

Accountability

High · Not assessed

No readiness evidence has been recorded for accountability.

Next action: Name owners and decision rights, then set the pilot success, stop, and escalation conditions.

Implementation sequence

01
Data paths
Map the end-to-end data path and approve what may move, be retained, or be logged.
Dependency: Any external or local AI processing boundary
02
Device fleet
Set the supported fleet and test the least capable device under representative conditions.
Dependency: Any on-device or hybrid feature
03
Model lifecycle
Define a version, evaluation, update, and rollback process before scaling the feature.
Dependency: Any model or prompt used in the workflow
04
Identity & access
Assign access roles, approval paths, and offboarding/review responsibilities for the intended workflow.
Dependency: Any shared data, account, or administration boundary
05
Outage fallback
Specify a user-visible fallback, timeout, recovery path, and owner for each material dependency.
Dependency: Any user-facing or operational workflow
06
Accountability
Name owners and decision rights, then set the pilot success, stop, and escalation conditions.
Dependency: Every pilot and production workflow

{
  "schemaVersion": "maha-architecture-readiness/0.1",
  "generatedAt": "2026-07-30T04:35:55.764Z",
  "status": "needs_review",
  "assessment": {
    "title": "",
    "workload": "",
    "accountableOwner": ""
  },
  "domains": [
    {
      "id": "data_paths",
      "name": "Data paths",
      "maturity": "not_assessed"
    },
    {
      "id": "device_fleet",
      "name": "Device fleet",
      "maturity": "not_assessed"
    },
    {
      "id": "model_lifecycle",
      "name": "Model lifecycle",
      "maturity": "not_assessed"
    },
    {
      "id": "identity_access",
      "name": "Identity & access",
      "maturity": "not_assessed"
    },
    {
      "id": "outage_fallback",
      "name": "Outage fallback",
      "maturity": "not_assessed"
    },
    {
      "id": "accountability",
      "name": "Accountability",
      "maturity": "not_assessed"
    }
  ],
  "gapRegister": [
    {
      "domain": "Data paths",
      "priority": "High",
      "status": "Not assessed",
      "gap": "No readiness evidence has been recorded for data paths.",
      "action": "Map the end-to-end data path and approve what may move, be retained, or be logged.",
      "dependency": "Any external or local AI processing boundary"
    },
    {
      "domain": "Device fleet",
      "priority": "High",
      "status": "Not assessed",
      "gap": "No readiness evidence has been recorded for device fleet.",
      "action": "Set the supported fleet and test the least capable device under representative conditions.",
      "dependency": "Any on-device or hybrid feature"
    },
    {
      "domain": "Model lifecycle",
      "priority": "High",
      "status": "Not assessed",
      "gap": "No readiness evidence has been recorded for model lifecycle.",
      "action": "Define a version, evaluation, update, and rollback process before scaling the feature.",
      "dependency": "Any model or prompt used in the workflow"
    },
    {
      "domain": "Identity & access",
      "priority": "High",
      "status": "Not assessed",
      "gap": "No readiness evidence has been recorded for identity & access.",
      "action": "Assign access roles, approval paths, and offboarding/review responsibilities for the intended workflow.",
      "dependency": "Any shared data, account, or administration boundary"
    },
    {
      "domain": "Outage fallback",
      "priority": "High",
      "status": "Not assessed",
      "gap": "No readiness evidence has been recorded for outage fallback.",
      "action": "Specify a user-visible fallback, timeout, recovery path, and owner for each material dependency.",
      "dependency": "Any user-facing or operational workflow"
    },
    {
      "domain": "Accountability",
      "priority": "High",
      "status": "Not assessed",
      "gap": "No readiness evidence has been recorded for accountability.",
      "action": "Name owners and decision rights, then set the pilot success, stop, and escalation conditions.",
      "dependency": "Every pilot and production workflow"
    }
  ],
  "implementationSequence": [
    {
      "step": 1,
      "domain": "Data paths",
      "action": "Map the end-to-end data path and approve what may move, be retained, or be logged.",
      "whyNow": "Any external or local AI processing boundary"
    },
    {
      "step": 2,
      "domain": "Device fleet",
      "action": "Set the supported fleet and test the least capable device under representative conditions.",
      "whyNow": "Any on-device or hybrid feature"
    },
    {
      "step": 3,
      "domain": "Model lifecycle",
      "action": "Define a version, evaluation, update, and rollback process before scaling the feature.",
      "whyNow": "Any model or prompt used in the workflow"
    },
    {
      "step": 4,
      "domain": "Identity & access",
      "action": "Assign access roles, approval paths, and offboarding/review responsibilities for the intended workflow.",
      "whyNow": "Any shared data, account, or administration boundary"
    },
    {
      "step": 5,
      "domain": "Outage fallback",
      "action": "Specify a user-visible fallback, timeout, recovery path, and owner for each material dependency.",
      "whyNow": "Any user-facing or operational workflow"
    },
    {
      "step": 6,
      "domain": "Accountability",
      "action": "Name owners and decision rights, then set the pilot success, stop, and escalation conditions.",
      "whyNow": "Every pilot and production workflow"
    }
  ],
  "evidenceRecorded": [],
  "limits": [
    "This is a self-reported, browser-local planning record. It does not inspect systems or verify controls.",
    "It is not a security, privacy, legal, accessibility, procurement, cost, performance, or sovereignty assessment or certification.",
    "An accountable owner should validate evidence and obtain appropriate technical and organizational review before implementation."
  ],
  "references": [
    "https://www.mahastrategies.com/tools/ai-boundary-planner",
    "https://www.mahastrategies.com/mps/learn/implementation"
  ]
}

Use the result well

Use this after defining a workload in the AI Boundary Planner. The assessment identifies what must be evidenced before a limited pilot or broader implementation; it does not replace technical, legal, privacy, security, accessibility, or procurement review.