From charter to connected capabilities

I think a useful deployment methodology should make readiness visible. Before building a capability, we should be able to name its purpose, identify its data, describe its contract, and say who is responsible when it fails.

This is the gated sequence behind my deployment methodology. Each phase leaves an artifact that the organization can inspect and maintain. The phases describe dependencies rather than a promise that every business should move through them at the same speed.

The principles behind the sequence

Every phase should produce something useful beyond the engagement that created it: a charter, an ownership map, a versioned contract, a tested function, or an operating record. Knowledge should remain with the organization and the people responsible for its work.

Entry and exit criteria keep uncertainty explicit. If a prerequisite is missing, the next phase should either wait or proceed within a clearly acknowledged, narrower scope. A gate is useful when it explains what remains unknown and who has accepted that uncertainty.

Data availability governs function scope. It is easy to describe an attractive capability in a workshop. The harder question is whether the required information exists, can be interpreted, and may be used for that purpose.

The Role Programming Interface is also a living artifact. A stable contract protects consumers while its implementation changes. Stability does not mean freezing a mistaken contract forever; revisions need versioning, ownership, and an agreed migration path.

Phase 0a — Governance

The starting conditions are a committed executive sponsor and a defined scope: the enterprise, a business unit, or a department. The work is to agree on the objective, the principles that constrain it, the kinds of decisions AI may support or execute, and the people responsible for exceptions.

I would use this phase to define success conditions, risk posture, data boundaries, and decision rights. The aim is a practical decision framework that lets downstream teams move with clear authority.

Two artifacts matter most: an AI governance charter and a decision-rights matrix. The charter records the purpose and boundaries. The matrix identifies who may approve what at executive, department, and individual levels.

The exit condition is agreement by the sponsor and the department owners who must operate within it. If they interpret the same boundary differently, the ambiguity should be resolved before it becomes a runtime decision.

Phase 0b — Data readiness

This phase examines whether the proposed capabilities have a dependable data foundation. The entry conditions are identified systems and owners, appropriate access, and the governance context needed to decide what may be used.

My working assessment draws on five areas associated with DAMA-DMBOK: data quality, data governance, master data management, metadata management, and data architecture. This is a selected assessment scope for the methodology, not a claim to cover the entire body of knowledge or award a certification.

For each domain, identify the authoritative source, missing or inconsistent information, ambiguous ownership, and constraints on use. Assess readiness against the actual functions under consideration. The same dataset can be adequate for one decision and inadequate for another.

The outputs are an assessment, a data-ownership map, a readiness matrix, and a remediation roadmap ordered by capability dependencies. Departments with usable inputs can proceed within that scope; those with blocking gaps need remediation first.

An existing assessment can be evidence, but I would check its scope, age, and whether the systems have changed since it was performed. The original methodology proposed a twelve-month freshness check. The underlying question is whether the assessment still describes the environment we are about to use.

Phase 1 — Map the Role Programming Interface

Once target departments have adequate data and engaged owners, define their organizational interfaces. What does each department own, consume, and produce? Which capabilities do others depend on? What must be true before those capabilities can be invoked?

The mapping covers data assets, functions, exposure levels, schemas, service expectations, and failure behavior. Exposure can be internal, partner-facing, or public, with permissions appropriate to each case. The dependency graph shows which functions consume other departments’ outputs.

The main artifact is a versioned RPI specification for each department, supported by a schema library. An internal extension records implementation concerns such as human gates, skill references, and escalation paths.

interfaces/
├── customer-success.rpi.yaml
├── customer-success.rpi.internal.yaml
├── billing.rpi.yaml
└── billing.rpi.internal.yaml
schemas/
├── account-context.json
├── expansion-request.json
└── billing-quote.json

The file names illustrate the separation. A consumer needs to understand the published contract; it does not need every internal instruction used to fulfill it.

This phase ends when the department owner accepts the specification, dependent teams agree on their handoffs, and the schemas and internal boundaries have been reviewed. A contract is not ready merely because a file parses.

Phase 2 — Build what fulfills the contract

The next phase constructs the implementation behind the interface. Its inputs are the accepted RPI specifications, a scoped technical environment, and identified engineering or operations owners.

Work includes agent skills, deterministic logic, tool integration, human approval gates, and escalation paths. Each function needs an explicit operating mode: human-led, assisted, or authorized for routine autonomous execution under defined conditions.

MCP servers are one possible way to expose department capabilities to authorized agents. The interface contract remains the important boundary; the transport and runtime should fit the environment.

Integration checks should establish that inputs and outputs conform to the schemas, but also that the function does the intended work. Exercise timeouts, retries, fallbacks, permission failures, missing data, and denied approvals. A function that works only when every dependency cooperates is not ready to become another team’s dependency.

The outputs are the implemented capability library, its endpoints, tested human gates, an integration test suite, and a deployment runbook. The owning team must be able to operate and maintain them. Exit criteria should cover expected behavior and failure behavior, not simply endpoint availability.

Phase 3 — Integrate the individual role

Department capabilities become more useful when people can invoke them with the context of their actual role. This phase begins after at least one department has functioning infrastructure and the target roles have been identified.

A RoleOS-compatible context package can combine role objectives, responsibilities, approved information, tools, and decision boundaries. The person gains access to relevant department functions without being expected to understand every implementation detail.

Not every useful task will already be a formal function. One-off work is a source of discovery. If a request recurs, record the pattern and consider whether it belongs in the shared capability map.

The promotion pathway returns to Phase 1: define the candidate function, check its data and ownership, agree on its contract, then build and evaluate it. Repetition is a reason to investigate a capability, not automatic permission to deploy one.

The phase leaves role context packages, tool configurations, an enablement guide, and a working feedback process. A useful exit check is whether people can actually operate the tools and whether one candidate has completed the review pathway.

Phase 4 — Explore external interoperability

Only after internal dependencies are stable would I consider exposing selected capabilities to external counterparties. The conditions include a willing partner, agreed data boundaries, appropriate review, and a charter that covers the external relationship.

Both sides need to align schemas, authentication, service expectations, failure handling, and versioning. A capability that works well inside one organization may rely on assumptions a partner cannot see.

The outputs are the approved external specifications, an onboarding package, and a cross-organization dependency map. A meaningful first test is a permitted invocation by the counterparty with observable handling of both success and failure.

My earlier notes imagine a shared RPI registry as a way to discover compatible interfaces. I regard that as a possible future element of the architecture, not an assertion that a public standard or operating registry already exists.

What should accumulate across the phases

After governance and readiness work, the organization should understand what it is trying to do and which information can support it. After interface mapping, it should have an explicit description of its capabilities. After implementation, those capabilities should be usable through tested contracts.

Individual integration then creates a route for new patterns to improve the map. External integration extends only the parts whose boundaries are understood. The sequence can repeat as the business changes.

The intended compounding asset is reusable knowledge: definitions, evaluation cases, schemas, operating experience, and better decisions about what to build next. Whether costs fall or outcomes improve must be measured. The methodology earns its value by making those questions answerable.

Adapted for this notebook from my Deployment Methodology v0.1.