01 / MANDATE

Own the path, not every application.

The role owns the enterprise path for delivering AI: architecture, shared capability, trust, decisions, adoption, and evidence. Product teams still own the domain application and business outcome.

Define and operationalize the foundational AI architecture that lets teams build, govern, deploy, and operate identity-bound AI solutions safely and repeatedly.

Direction

01

Turn uncertainty into explicit options, trade-offs, recommendations, and architecture decisions.

Foundation

02

Identify common AI concerns and shape them into reusable platform capabilities.

Trust

03

Translate identity, security, legal, risk, evaluation, and provenance into implementable controls.

Adoption

04

Create paved roads, examples, and operating contracts that let teams move independently.

02 / SCOPE

Foundational AI is a platform capability.

The architect establishes clear boundaries between reusable platform responsibilities and domain-specific application responsibilities.

08
Developer experience
SDKs, templates, IDE and MCP integrations, documentation, golden paths.
07
Evaluation and observability
Quality gates, traces, metrics, cost, feedback, audit events.
06
Policy and governance
Risk tiers, model allowlists, human approval, provenance, retention.
05
Identity and authorization
Delegated identity, entitlements, tool permissions, service identities.
04
Agents and tools
MCP registry, orchestration, tool contracts, action boundaries.
03
Knowledge and retrieval
Ingestion, hybrid search, GraphRAG, lineage, source attribution.
02
Model gateway
Abstraction, routing, fallback, quotas, provider policy, cost attribution.
01
Core platform integration
Cloud, APIs, CI/CD, secrets, networking, catalogs, operations.

Platform owns the repeatable burden

  • Shared contracts and lifecycle.
  • Common controls and production defaults.
  • Reusable evaluation and telemetry.
  • Platform reliability and support.
  • Discovery, documentation, and onboarding.

Application teams own the domain

  • Customer problem and product outcome.
  • Domain prompts and evaluation criteria.
  • Application code, UX, and integrations.
  • Application SLOs and on-call.
  • Adoption and business-value realization.
03 / OPERATING MODEL

Switch modes intentionally.

The architect creates leverage by knowing when to define, enable, productize, or intervene—and when to exit.

Architecture

Define direction

Target states, boundaries, trade-offs, interfaces, NFRs, and decisions.

  • Exit when the decision is implementable.
  • Do not become a permanent approval gate.
Enablement

Transfer capability

Coach a team through a first implementation or unfamiliar technical risk.

  • Pair, demonstrate, observe, transfer.
  • Exit when the team can repeat it.
Platform product

Convert repetition

Turn recurring needs into APIs, SDKs, templates, policies, or services.

  • Prioritize by consumer friction.
  • Measure adoption and avoided effort.
Escalation

Resolve systemic risk

Enter deeply when architecture, security, or production uncertainty blocks delivery.

  • Remove the systemic uncertainty.
  • Return delivery ownership afterward.
04 / SOFT SKILLS

Soft skills are the architecture control plane.

They create clarity, trust, movement, and durable capability across teams without formal authority.

Diagnostic curiosity

Separate the request from the actual problem, constraint, and measurable outcome.

CapableClarifies requirements.
StrongFinds hidden assumptions.
ExceptionalImproves how teams frame future AI problems.

Translation across altitude

Hold the facts constant while changing the abstraction for engineering, risk, and executives.

CapableExplains clearly.
StrongTailors by audience.
ExceptionalCreates one shared language across disciplines.

Decision leadership

Move with bounded assumptions and match decision rigor to consequence.

CapablePresents options.
StrongDrives timely decisions.
ExceptionalImproves organizational decision quality.

Influence without authority

Build coalitions around evidence, trade-offs, and useful mechanisms.

CapableGains cooperation.
StrongResolves cross-team conflict.
ExceptionalCreates durable alignment that survives the meeting.

Constructive dissent

Challenge the decision without threatening the people involved.

CapableRaises concerns.
StrongProvides options and recommendation.
ExceptionalStrengthens trust through hard decisions.

Ownership with boundaries

Own the outcome within authority without absorbing every missing role.

CapableFollows through.
StrongNames owners and dependencies.
ExceptionalCreates autonomy without abandoning accountability.

Product empathy

Treat developers and consuming teams as customers of the platform.

CapableUnderstands consumer needs.
StrongReduces platform friction.
ExceptionalCreates voluntary adoption and lower cognitive load.

Intellectual humility

Make a clear recommendation while showing where the evidence is weakest.

CapableAccepts feedback.
StrongUpdates from evidence.
ExceptionalModels public correction without losing authority.

Composure

Communicate bad news, pressure, and uncertainty without transmitting panic.

CapableStays professional.
StrongSurfaces risk early.
ExceptionalMakes the room more useful under pressure.
05 / EXCEPTIONAL

Exceptional means the organization improves around you.

The highest level is not more personal activity. It is compounding decision quality, reuse, trust, and team independence.

Dimension
Meets
Strong
Exceptional
Problem framingClarifies requirements.Finds hidden constraints.Changes how teams frame AI problems.
DecisionsDocuments options.Drives an accountable choice.Creates reusable decision mechanisms.
Platform thinkingUses existing patterns.Creates shared capability.Reduces enterprise cognitive load.
InfluenceBuilds relationships.Resolves conflict.Creates coalitions that endure.
TeachingHelps individuals.Develops technical leads.Creates self-sufficient teams and teachers.
RiskRaises concerns.Designs controls.Connects evidence to the correct authority.
Failure responseFixes the issue.Finds the systemic cause.Changes the default so it is harder to repeat.
06 / COLLABORATION

Architecture succeeds through an explicit role system.

Each partner owns a distinct part of the outcome. Collaboration should connect the roles, not erase their boundaries.

Manager / platform leader

Creates organizational authority and capacity.

OwnsRole charter, ranked priorities, staffing, escalation, performance measures, and conflict resolution.
Does not delegate awayPriority trade-offs, staffing decisions, or risk appetite by leaving them ambiguous.

Senior Solutions Architect

Creates technical clarity and cross-system coherence.

OwnsArchitecture, recommendations, technical risk, decision packages, reference patterns, and enablement.
Does not silently ownEvery prototype, sprint commitment, product roadmap, or application on-call.

Platform engineering

Turns accepted architecture into supported capability.

OwnsPlanning, implementation, tests, CI/CD, SLOs, runbooks, operations, maintenance, and delivery evidence.
Does not treatArchitecture as a handoff or a reference implementation as transferred production ownership.

Product / business owner

Owns customer value and prioritization.

OwnsProblem, users, desired outcome, adoption, roadmap priority, funding rationale, and value realization.
Does not transferBusiness ownership to the architect because the solution uses AI.

Security, identity, legal, risk

Define and approve control requirements.

OwnsPolicy interpretation, control authority, exceptions, risk acceptance, and legal or privacy judgment.
Does not requireEvery team to rediscover the same controls when a reusable pattern can be approved.

Consuming engineering team

Builds and operates the domain solution.

OwnsApplication design, domain evaluation, integration, user experience, SLOs, support, and application incidents.
Does not outsourceApplication ownership to Core Platform because it consumes a platform service.
07 / WHAT IT IS NOT

Protect the role from becoming organizational glue.

The architect bridges gaps long enough to expose, shape, and route them. Permanent absorption hides the underlying ownership problem.

Not the default product owner

You may shape use cases and measures. Product still owns customer priority and value realization.

Not the engineering manager

You may identify capacity risk. Management assigns people, resolves priorities, and manages performance.

Not the permanent implementation team

You may build the spike or reference. Engineering hardens, ships, operates, and maintains the service.

Not the risk acceptance authority

You explain the risk and design controls. The designated authority accepts or rejects residual risk.

Not an architecture gatekeeper

The objective is safe autonomy through standards, evidence, and paved roads—not centralized permission for every decision.

Not the recurring incident hero

Repeated rescue is a signal to create ownership, observability, automation, or a platform mechanism.

08 / ACCOUNTABILITY

Require decisions from the roles that hold authority.

You can require your manager to make the organizational contract explicit. You can require engineering to provide implementation and operational evidence.

Decision or deliverableArchitectManager / productEngineeringControl functions
Role charter and prioritiesAdvise on impactDecide and rankSupply capacity evidenceContribute constraints
Target architectureDrive / decide when delegatedApprove investment implicationsValidate feasibilityValidate controls
Delivery commitmentReview dependenciesCommit priority and capacityEstimate and deliverState review timing
Production readinessDefine cross-platform criteriaAccept launch implicationsProduce evidence and operateApprove required controls
Risk exceptionExplain and recommendOwn business consequenceImplement compensating controlsApprove or reject
Application business valueConnect architecture to outcomeOwn outcome and adoptionSupply technical measuresContribute risk measures

Manager decisions you can require

  • Written mandate and role boundaries.
  • Top outcomes in ranked order.
  • Success measures and expected hands-on depth.
  • Decision rights: decide, recommend, drive, contribute.
  • Named engineering owner and capacity.
  • Escalation path and default when a decision is late.
  • Which work stops when new work enters.

Engineering evidence you can require

  • Implementation plan, estimates, dependencies, and risk.
  • Architecture conformance or a documented exception.
  • Tests, evaluation, and security verification.
  • SLOs, dashboards, alerts, runbooks, rollback, and on-call.
  • Production telemetry and completion evidence.
  • Named service owner and maintenance plan.
09 / BRIDGE THE GAP

Convert friction into a decision object.

Do not report frustration. Report the observable state, consequence, recommendation, owner, and date.

AvoidNobody from engineering is taking ownership.
UseThe architecture is ready. No engineering owner or capacity is assigned, so the milestone is uncommitted. I recommend Team X because it owns the adjacent service. The ownership decision is needed Friday.
AvoidThe priorities keep changing.
UseThree requests were added. Capacity supports two active outcomes. I recommend retaining identity-bound tool access and model routing, and moving the assistant use case to backlog. Please confirm the ordering.
AvoidEngineering ignored the design.
UseThe implementation uses a shared privileged identity rather than delegated user identity. That creates a conformance gap. Engineering should align the implementation or submit a risk exception with an approver.
AvoidI am doing everyone else’s work.
UseI completed the reference implementation to remove feasibility risk. Production hardening, CI/CD, support, and service ownership now require an assigned engineering team. I will remain engaged for architecture review and escalations.
Bridge the gap, but make the gap visible. Help close it, but do not silently become its permanent owner.
10 / ADR + RFC DECISION OS

Before the break. At the break. After the break.

Use a lightweight decision lifecycle to detect uncertainty early, control production breaks, and convert learning into durable architecture, delivery work, and conformance.

Before the break

Shape uncertainty while options are still cheap.

Detect irreversible choices, new trust boundaries, cross-team impact, unclear ownership, weak evidence, and production assumptions before implementation hardens them.

  • Open an RFD while the problem and solution space are fluid.
  • Use an RFC before platform services, public contracts, material AI capabilities, vendor commitments, or costly migrations.
  • Name one driver, one approver, a risk tier, and a decision date.
  • Require goals, non-goals, alternatives, evidence, rollout, and rollback.
  • Run pre-mortems, threat models, evaluation baselines, and readiness reviews.
OUTPUT → decision-ready proposal
At the break

Contain first. Preserve evidence second. Avoid redesign by adrenaline.

During an incident or failed delivery, separate immediate containment from architectural judgment. Capture enough context to reconstruct what actually happened.

  • Assign incident command, technical lead, communications, and scribe roles.
  • Record timeline, user impact, traces, decisions, workarounds, and unresolved risk.
  • Use temporary exceptions with owner, expiry, compensating control, and rollback.
  • Do not convert the incident channel into an unreviewed architecture forum.
  • Tag suspected ADR/RFC assumptions that may have been invalidated.
OUTPUT → contained impact + evidence package
After the break

Change the system, not only the incident ticket.

Decide whether the break exposed an implementation defect, missing control, invalid assumption, architecture decision, platform gap, or ownership gap.

  • Publish a learning review with systemic cause and decision implications.
  • Create or supersede the ADR when the accepted architecture changes.
  • Update the RFC when scope, assumptions, risk, or rollout strategy changes.
  • Create delivery actions, ORR gates, conformance rules, tests, and owner dates.
  • Carry ADR IDs into code, service catalogs, API specs, policies, dashboards, and runbooks.
OUTPUT → safer default + traceable evolution
ARTIFACT ROUTER

Use the artifact that answers the current question.

RFD

Request for Discussion

Is this problem worth developing, and what should be learned before committing?

Use: Discovery, contested problem framing, early exploration.
RFC

Request for Comments

Should the organization adopt this substantial proposal?

Use: Cross-team, high-impact, risky, expensive, or hard-to-reverse change.
ADR

Architecture Decision Record

What was decided, why, under which guardrails, and what triggers reconsideration?

Use: After approval and before the decision spreads across teams.
DESIGN

System Design

How does the accepted architecture work now?

Use: Implementation truth, interfaces, flows, security, failure behavior.
ORR

Operational Readiness Review

Can this system be safely operated, supported, recovered, and audited?

Use: Before production or material capability graduation.
LR

Learning Review

What assumption, control, mechanism, or ownership model failed?

Use: After incidents, failed pilots, near misses, or repeated exceptions.
TRIGGERS

Scale the ceremony to consequence.

Change profile
Minimum artifact
Review
Evidence / gate
Local and reversibleDesign note or small ADROwning teamTests and code review
Cross-team contractRFC → ADRAffected teams + approverCompatibility and migration plan
New trust boundaryRFC + threat model → ADRIdentity / security / privacyControl evidence and abuse cases
Material AI capabilityRFC + evaluation plan → ADRAI platform, product, riskBaseline, thresholds, failure analysis
Production launchORR linked to ADR / designEngineering, operations, ownersSLOs, rollback, runbooks, alerts
Incident invalidates assumptionLearning review + superseding ADROwners and decision authorityRegression test and conformance gate

Minimum RFC decision package

  • Decision requested—not merely “feedback wanted.”
  • Status, driver, approver, risk tier, deadline, affected systems.
  • Current state, goals, non-goals, drivers, and constraints.
  • Proposed architecture and interfaces.
  • Alternatives and trade-offs.
  • Security, data, operations, evaluation evidence.
  • Migration, rollout, rollback, and feedback disposition.

Minimum ADR record

  • Context and decision drivers.
  • Options considered.
  • Explicit decision statement.
  • Rationale and consequences.
  • Guardrails and conformance rules.
  • Validation evidence.
  • Review and supersession triggers.
  • Linked implementation and follow-up actions.
Anti-pattern: AI evidence laundering

A polished demonstration is presented as proof. Require representative datasets, baselines, thresholds, reproducible model and prompt versions, and explicit failure analysis.

Anti-pattern: unbounded conditional approval

Major concerns become an informal backlog. Every condition needs an owner, due date, tracking item, evidence requirement, and explicit blocking designation.

Anti-pattern: document by committee

Many authors flatten the narrative into contradictions. One driver owns the proposal. Contributors comment, supply evidence, or propose explicit edits.

Anti-pattern: Confluence–code divergence

The decision cannot be found from the implementation. Carry ADR IDs into repositories, service catalogs, API specifications, policies, runtime metadata, dashboards, and runbooks.

11 / TOOLING

Documentation informs. Mechanisms enforce.

Use tools to reduce missing information, time-box review, preserve provenance, verify conformance, and make the safer path the easier path.

Before the break

Confluence templates + approvals

Standardize RFC/ADR metadata, required sections, review states, approvers, due dates, and approval history.

  • Use pages—not ephemeral chat—as the review record.
  • Generate decision registers with page properties and labels.
  • Require one accountable approver.

Confluence approvals guidance

Before the break

Jira workflows and issue forms

Turn decisions and conditions into owned delivery work instead of leaving them inside comments.

  • Required owner, due date, risk tier, evidence, and blocking state.
  • Workflow gates for review, approval, implementation, readiness, and validation.
  • Automated stale-decision and expired-waiver reports.

GitHub issue and PR templates

Before the break

Architecture-as-code

Keep diagrams, contracts, and decisions close enough to implementation that drift is visible.

  • Mermaid, Structurizr, PlantUML, OpenAPI, AsyncAPI.
  • Repository-owned design and ADR folders.
  • PR previews and diff review for diagrams and contracts.
Before the break

Evaluation harnesses

Replace demo confidence with repeatable evidence for models, retrieval, agents, and safety.

  • Golden datasets and task rubrics.
  • Prompt and model version capture.
  • Regression thresholds and release gates.
  • Representative failure scenarios.
At the break

OpenTelemetry correlation

Preserve end-to-end evidence across gateway, retrieval, model, policy, and tool execution.

  • Trace and span IDs in logs.
  • Model, prompt, tool, policy, and ADR identifiers as safe attributes.
  • Privacy-aware sampling and redaction.

OpenTelemetry documentation

At the break

Incident command + evidence capture

Use a structured incident channel, timeline, owner roles, and temporary exception record.

  • Containment, impact, decision, and rollback timestamps.
  • Link the affected service, ADR, RFC, release, and dashboards.
  • Separate facts, hypotheses, and decisions.
At the break

Feature flags and kill switches

Make AI autonomy, model routes, tools, and risky capabilities independently disableable.

  • Read-only fallback.
  • Provider or model isolation.
  • Tool-level deny switches.
  • Progressive exposure and rollback.
After the break

Backstage catalog + TechDocs

Make current ownership, documentation, ADRs, APIs, SLOs, dashboards, and runbooks discoverable from the service.

  • ADR and RFC annotations.
  • System, component, API, and owner relationships.
  • Docs stored with code and published through the catalog.

Backstage TechDocs

After the break

Policy as code

Convert accepted guardrails into testable rules for configuration, IaC, deployment, and runtime authorization.

  • OPA / Rego and Conftest in CI.
  • Model allowlists, region restrictions, required metadata.
  • Waiver IDs and expiry enforcement.

OPA in CI/CD

After the break

Architecture conformance tests

Turn high-value ADR guardrails into executable checks.

  • Dependency and layering tests.
  • API linting and compatibility checks.
  • Identity, network, and data-policy assertions.
  • Required status checks before merge.

ArchUnit motivation

After the break

Required PR checks

Require the evidence linked to the decision before code can merge.

  • ADR or RFC reference when architectural paths change.
  • Evaluation, policy, security, and compatibility checks.
  • CODEOWNERS for affected domains.
  • Rulesets and protected branches.

GitHub PR standardization

After the break

Decision health dashboards

Measure whether the process is improving delivery or becoming ceremony.

  • Time to decision and review latency.
  • Accepted RFCs without delivery links.
  • Released systems without ORR evidence.
  • Expired waivers and stale ADRs.
  • Repeated incidents tied to the same guardrail.
GAP → MECHANISM

Choose the mechanism that removes recurrence.

Repeated ambiguity
Teams disagree on problem or scope.
RFD + decision brief
One driver, bounded questions, approver, deadline.
Repeated review debate
The same architecture argument returns.
ADR + searchable decision log
Preserve rationale, guardrails, and supersession triggers.
Implementation drift
Code no longer reflects the accepted architecture.
Conformance check
Architecture tests, policy as code, contract linting, required status.
Late operational surprise
Ownership, SLO, rollback, or capacity is missing.
ORR gate
Evidence-based readiness before release or graduation.
Recurring incident
The same failure mode returns.
Superseding ADR + platform control
Change the decision, default, test, or shared service.
Architect dependency
Every team needs synchronous interpretation.
Paved road + catalog
Template, SDK, examples, ownership, and self-service documentation.
12 / PRACTICE

Run a small, visible operating cadence.

The role becomes credible through repeated behaviors: clear priorities, decision flow, engineering evidence, consumer feedback, and learning conversion.

Priority and dependency review

Confirm the top outcomes, new requests, displaced work, owner gaps, and decisions due this week.

Architecture office hours

Use bounded enablement for novel problems. Route substantial proposals into the RFC lifecycle.

Decision and evidence review

Resolve material feedback, validate evaluation evidence, and take decision-ready questions to approvers.

Engineering conformance

Review implementation evidence, exceptions, operational readiness, and platform capability gaps.

Learning and leverage

Convert repeated questions, incidents, and manual reviews into templates, tests, policies, SDKs, or roadmap proposals.

Weekly questions

  • What decision is blocked, and who is the approver?
  • What new request displaces existing work?
  • What architecture assumption has weak evidence?
  • What does engineering need to prove this week?
  • What repeated friction should become a platform capability?
  • What exception is approaching expiry?

Quarterly health review

  • Platform adoption and avoided engineering effort.
  • Time from idea to decision to production.
  • RFC review latency and unresolved ambiguity.
  • ADRs without linked conformance or delivery.
  • Incidents that invalidated architecture assumptions.
  • Areas still dependent on architect heroics.
13 / SCORECARD

Measure leverage, not visible activity.

Use the assessment as a conversation starter. The highest score is not the objective; explicit gaps and next mechanisms are.

Assessment: Emerging

Start by making owners, decision rights, and the first high-impact RFC explicit.

14 / SOURCES

Research and operating-model provenance.

This guide synthesizes the role research and the DecisionOS RFC/ADR research. Linked material is used for role patterns, decision lifecycle, approvals, docs-as-code, policy enforcement, architecture testing, and observability.

Decision records and review systems
Workflow and enforcement tools
AI risk, readiness, and platform practice
Artifact metadata

Artifact: Core Platform AI Role Guide

Version: 2.0.2

Reviewed: July 18, 2026

Method: Primary-source research synthesis, prior DecisionOS research, user-directed role framing, and mobile-first implementation.