Understand
Which outcomes the platform enables, where investment is required, and how risk and value are measured.
01 Orientation
One body of knowledge. Multiple decision views.
The page is intentionally ordered from orientation to execution. Select an audience lens to emphasize the material most relevant to that role without hiding the rest of the architecture.
Decide
Capability boundaries, contracts, trade-offs, transition architecture, standards, and decision history.
Implement
APIs, SDKs, reference paths, validation gates, failure behavior, and operational expectations.
Control
Identity, rights, model exposure, policy enforcement, retention, approval, exceptions, and auditability.
02 Mission
Make AI a first-class platform capability.
Enable AI-assisted products and workflows without forcing each team to rebuild the same model access, identity, rights, retrieval, evaluation, telemetry, cost, and operational controls.
Mission statement
Make AI a reusable capability of the NBA content delivery platform while preserving identity, rights, security, reliability, provenance, and business accountability.
Business-led
Begin with the workflow, outcome, decision, and constraints. Select technology after capability demand is understood.
Governed by default
Shared pathways apply policy, evidence, evaluation, cost, and audit controls before product-specific logic runs.
Evidence-managed
Claims, assumptions, decisions, confidence, conflicts, review dates, and production findings remain traceable.
Identity before intelligence
Resolve the requester, delegated authority, role, audience, entitlement, and intended use before retrieval or inference.
Rights before retrieval
Content eligibility is determined before content enters model context. The model never decides access permission.
Deterministic controls outside the model
Authorization, budgets, tool permissions, territory restrictions, and approval gates are enforced by infrastructure-level controls.
Model-agnostic, not lowest-common-denominator
Stable platform operations remain portable. Provider-specific capabilities are explicit, versioned extensions.
Protocols are adapters
MCP and A2A support interoperability. They do not replace authorization, rights, governance, audit, or product architecture.
Earn autonomy
Execution authority increases only when evidence demonstrates reliable operation within defined risk and resource envelopes.
03 Operating model
Seven planes connect demand to evidence.
The planes separate responsibilities without isolating them. The Control Plane constrains all execution. The Evidence Plane feeds business and platform decisions.
Target operating architectureScroll horizontally when needed
flowchart TB
D["1. Demand Plane
Business initiatives and outcomes"]
P["2. Platform Product Plane
Capabilities, patterns and golden paths"]
C["3. Control Plane
Identity, rights, policy and governance"]
E["4. Execution Plane
Models, agents, workflows and tools"]
K["5. Knowledge Plane
Content, metadata, search, graph and lineage"]
O["6. Evidence Plane
Telemetry, evaluations, audit and research"]
X["7. Experience Plane
Products, channels and developer interfaces"]
D --> P
P --> X
X --> C
C --> E
E --> K
E --> O
K --> O
X --> O
O --> D
O --> P
C -. constrains .-> P
C -. constrains .-> E
C -. constrains .-> K
C -. constrains .-> X
1
Demand Plane
Expresses why work should exist: sponsor, audience, outcome, workflow, constraints, expected reach, urgency, and success metric.
2
Platform Product Plane
Turns repeated needs into owned capabilities, golden paths, SDKs, SLOs, support tiers, adoption measures, and lifecycle states.
3
Control Plane
Makes deterministic decisions about identity, authorization, rights, governance, budgets, limits, regions, and delegated authority.
4
Execution Plane
Performs bounded inference, grounded generation, workflows, tool calls, agents, retries, approval, compensation, and output validation.
5
Knowledge Plane
Makes content, metadata, statistics, documentation, lineage, search, vector, graph, entity, and citation services safely usable.
6
Evidence Plane
Combines operational, quality, risk, cost, adoption, and business evidence. Converts production behavior into portfolio learning.
7
Experience Plane
Exposes capabilities to consumer, employee, partner, and developer experiences through shared contracts and controls.
04 Control Plane
Issue a deterministic execution envelope before AI runs.
No model invocation, retrieval request, tool execution, or agent delegation should proceed until identity, use-case registration, permissions, rights, limits, and policy versions are resolved.
Identity
- Human, service, and agent identity
- Delegation chain
- Roles and tenant context
Authorization
- Models and tools
- Resources and actions
- Distribution and delegation
Rights
- Territory and audience
- Time, embargo, expiration
- Channel and derivative use
Governance
- Use case and risk profile
- Model and policy approval
- Exceptions and expiration
Resources
- Token and cost budgets
- Iterations and concurrency
- Retry and duration limits
Approval
- Human-in-the-loop thresholds
- Irreversible action gates
- Escalation and recovery
TypeScript · execution-envelope.ts
type ExecutionEnvelope = {
requestId: string;
actor: {
subjectId: string;
actorType: "human" | "service" | "agent";
delegatedBy?: string;
roles: string[];
};
useCase: {
id: string;
riskProfileId: string;
environment: "development" | "test" | "production";
};
permissions: {
models: string[];
tools: string[];
contentScopes: string[];
permittedActions: string[];
};
constraints: {
territory?: string[];
audience?: string[];
expiresAt: string;
maxCostUsd?: number;
maxIterations?: number;
humanApprovalRequired: boolean;
};
policy: {
bundleId: string;
version: string;
decisionId: string;
};
};
Non-negotiable boundary
A probabilistic model can recommend an action. It cannot be the authoritative enforcement point for access, financial limits, content rights, production mutation, or approval requirements.
05 Execution
Classify execution before selecting architecture.
A bounded inference request and an autonomous multi-agent workflow are not the same operational object. Their controls, evidence, retry behavior, cost surfaces, and release pathways must differ.
| Class | Behavior | Example | Primary controls |
|---|---|---|---|
| Inference | Single bounded model request | Summarization | Input policy, model eligibility, output validation |
| Grounded inference | Model request with governed evidence | Content Q&A | Rights-aware retrieval, citations, freshness |
| Deterministic workflow | Known sequence containing AI steps | Metadata enrichment | Schema validation, idempotency, retries |
| Adaptive workflow | Model selects from approved next steps | Incident investigation | Tool scopes, iteration budgets, evidence capture |
| Agent | Iterative reasoning, memory, and tool use | Operations assistant | Agent identity, action gates, runtime telemetry |
| Multi-agent | Delegation across independent agents | Cross-domain research | Delegation policy, task lifecycle, trust boundaries |
Architecture implication
Agentic systems compound model calls, memory operations, tool use, delegation, latency, and cost. Treat them as a distinct production workload class.
06 Knowledge Plane
Make NBA knowledge usable without losing rights or lineage.
The Knowledge Plane combines content systems with retrieval, graph, taxonomy, entity, freshness, and citation services. Every result carries provenance and a rights decision.
Authoritative systems
Content APIs, CMS, game and player statistics, media metadata, partner content, platform documentation, telemetry, and incidents.
Retrieval services
Lexical, semantic, hybrid, vector, graph, reranking, temporal retrieval, entity resolution, citations, and lineage.
Mandatory filters
Identity, role, entitlement, territory, audience, content type, source, effective date, embargo, expiration, channel, and purpose.
TypeScript · governed-knowledge-result.ts
type GovernedKnowledgeResult = {
resultId: string;
contentId: string;
sourceSystem: string;
contentVersion: string;
retrievedAt: string;
relevance: {
lexical?: number;
semantic?: number;
rerank?: number;
};
rightsDecision: {
permitted: boolean;
policyVersion: string;
decisionId: string;
};
provenance: {
canonicalUri?: string;
createdAt?: string;
modifiedAt?: string;
lineageIds: string[];
};
citation: {
label: string;
locator?: string;
};
};07 Risk
Use a multidimensional profile—not a single risk label.
Audience, data, rights, autonomy, action authority, reversibility, scale, personalization, decision influence, and external dependency create different control needs.
Audience exposure
InternalPublic
Content rights complexity
ClearConstrained
Autonomy
AssistiveAutonomous
Action authority
Read-onlyIrreversible
Internal assistive
Authenticated employees, read-oriented, no irreversible actions, human validation, limited data scope.
Internal operational
Privileged users, production data or tools, bounded actions, complete audit, approval or compensation controls.
Partner or authenticated consumer
External identity, entitlement enforcement, contractual rights, stronger isolation, and formal quality thresholds.
Public consumer
Internet-scale abuse resistance, public-content restrictions, strict latency and reliability, continuous moderation and quality monitoring.
Autonomous high-consequence
Delegated authority, material external actions, explicit autonomy limits, dedicated threat modeling, approval, and incident response.
08 Adaptation
Translate every initiative through the same pathway.
The process avoids both uncontrolled experimentation and governance-by-committee. Common approvals become policy and conformance tests. Human review focuses on exceptions and consequence.
Initiative adaptation lifecycleEvidence loops back into design
flowchart LR
I["Initiative"] --> U["Use-case definition"]
U --> R["Risk profile"]
R --> M["Capability mapping"]
M --> S["Solution pattern"]
S --> G["Governance gates"]
G --> B["Build or configure"]
B --> V["Validate"]
V --> L["Launch"]
L --> E["Evidence and learning"]
E --> M
E --> R
Define the use case
User, workflow, input, output, consequence, affected systems, authority, volume, and success.
Create the risk profile
Determine control strength across independent dimensions rather than applying one broad classification.
Map capabilities
Classify each need as existing, configurable, extensible, reusable-new, or product-specific.
Select a pattern
Prefer supported compositions over custom architecture. Make deviations explicit.
Validate and launch
Apply technical, security, rights, quality, operations, cost, and business gates.
Feed evidence back
Use production findings to change risk profiles, platform priorities, patterns, evaluations, and decisions.
09 Patterns
Standardize compositions, not business experiences.
Solution patterns provide supported capability combinations. Product teams retain control over domain behavior and experience design.
Rights-aware grounded answer
Use for: content search, editorial research, partner Q&A, and fan conversational experiences.
Identity → entitlement and rights decision → governed retrieval → reranking → context assembly → model generation → citation validation → output policy → response.
Human-reviewed generation
Use for: articles, descriptions, marketing copy, translation, and metadata.
Approved inputs → generation → automated quality checks → human review → revision → approval → publication.
Read-oriented investigation agent
Use for: logs, incidents, architecture discovery, and lineage investigation.
Operator identity → scoped tools → evidence collection → hypotheses → supporting citations → recommended actions → operator decision.
Controlled action agent
Use for: remediation, content workflow updates, and bounded operational actions.
Intent → plan → policy evaluation → action preview → approval → idempotent execution → verification → audit → compensation.
Offline content enrichment
Use for: tagging, summarization, entity extraction, embeddings, and classification.
Content event → rights check → asynchronous processing → quality validation → versioned enrichment → index update → lineage record.
10 Evidence
Make the claim—not the document—the atomic research unit.
Documents become generated views over claims, evidence, decisions, capabilities, patterns, risks, ownership, and history. This allows one evidence base to serve multiple audiences.
Knowledge and publication architectureStructured source of truth
flowchart TB
SRC["Sources"] --> EVD["Evidence records"]
RUN["Research runs"] --> EVD
EVD --> CLM["Claims"]
CLM --> DEC["Decisions"]
DEC --> CAP["Capabilities"]
DEC --> PAT["Patterns"]
USE["Use cases"] --> PAT
PAT --> CAP
CLM --> ART["Published artifacts"]
DEC --> ART
CAP --> ART
PAT --> ART
USE --> ART
Typed claims
Fact, observation, analysis, inference, recommendation, and prediction remain distinct. Each has evidence, counter-evidence, confidence, applicability, owner, and review date.
Materialized views
Generate executive briefs, RFCs, ADRs, ADDs, threat models, engineering guides, service catalog pages, reports, decks, and backlogs from the same knowledge.
TypeScript · research-claim.ts
type ResearchClaim = {
id: string;
statement: string;
claimType:
| "fact"
| "observation"
| "analysis"
| "inference"
| "recommendation"
| "prediction";
applicability: string[];
evidenceIds: string[];
counterEvidenceIds: string[];
confidence: "low" | "medium" | "high";
uncertainty: string[];
owner: string;
reviewedAt: string;
reviewBy: string;
supersedes?: string[];
};11 Protocols
Terminate interoperability at governed boundaries.
MCP, A2A, provider APIs, event protocols, and future standards should be managed through a compatibility layer with versions, ownership, conformance tests, authentication models, and deprecation policies.
MCP
Use for governed access to tools, resources, prompts, IDE clients, and developer integrations. Keep authoritative authorization outside the MCP server.
A2A
Use when independent agents require discovery, task exchange, status, and cross-platform coordination. Resolve authorization through NBA identity and policy.
Provider APIs
Route through the AI gateway. Avoid direct production credentials and business coupling to provider-specific interfaces by default.
Boundary rule
Protocols standardize communication. NBA business APIs remain authoritative for content, rights, identity, workflow, and operational behavior.
12 Lifecycle
Manage capabilities from signal to retirement.
A capability does not become a standard because it is popular. It advances when business relevance, control strength, evidence, ownership, operations, cost, and adoption justify the transition.
Capability statesPromotion requires evidence
stateDiagram-v2
[*] --> Observe
Observe --> Research
Research --> Incubate
Incubate --> Supported
Supported --> Standard
Standard --> Deprecated
Deprecated --> Retired
Research --> Rejected
Incubate --> Rejected
Supported --> Deprecated
Rejected --> Observe
| State | Meaning | Adoption rule |
|---|---|---|
| Observe | Signal worth tracking | No implementation commitment |
| Research | Evidence, alternatives, applicability | No production dependency |
| Incubate | Bounded prototype or pilot | Explicit scope and exit criteria |
| Supported | Owned, documented, observable, evaluated | Approved production use |
| Standard | Preferred default | Exceptions require justification |
| Deprecated | No new adoption | Migration required |
| Retired | No longer supported | Access removed |
13 Measurement
Measure business value, not only platform adoption.
Adoption is an intermediate signal. The final test is whether shared capabilities improve outcomes while reducing duplication, risk, integration effort, and operational uncertainty.
Platform health
Shared-pathway adoption, direct integrations, reuse, SLOs, conformance, policy decisions, cost, migration, and exceptions.
AI quality
Task success, factuality, citations, retrieval precision, human acceptance, policy compliance, and regression frequency.
Developer experience
Time to first integration, golden-path usage, support load, duplication avoided, SDK adoption, and satisfaction.
Business value
Workflow time, engagement, editorial throughput, incident resolution, support deflection, partner adoption, and revenue impact.
Architecture fitness functions
Portability
An approved model can change without changing the product’s business integration.
Authorization
No model or agent accesses tools or content outside its execution envelope.
Rights
Expired, embargoed, geographic, audience, and channel restrictions prevent unauthorized context entry.
Traceability
Every response traces to identity, use case, model, prompt, context, sources, tools, policy, evaluations, and cost.
Reliability
Tool and model failures produce bounded retries, known degraded states, and explicit recovery.
Protocol isolation
Protocol and provider-version changes do not force business applications to redesign.
14 Workstreams
Six workstreams establish the first reusable system.
Governed AI pathway
API contract, identity, policy, model routing, audit, cost, validation, and an initial AWS Lambda/API Gateway TypeScript deployment.
Knowledge and lineage
Source catalog, ingestion, rights metadata, retrieval filters, citations, lineage, freshness, and GraphRAG evaluation.
Evaluation platform
Evaluation registry, golden datasets, offline tests, production sampling, human review, regression gates, and business measures.
Tool and agent platform
Tool registry, MCP boundary, permissions, action envelopes, idempotency, approval, telemetry, and A2A compatibility.
Developer experience
TypeScript SDK, CLI, IDE access, examples, local harness, templates, conformance, and documentation.
Research and decision system
Claim ledger, evidence taxonomy, RFC/ADR integration, capability registry, risk register, renderer, releases, and change history.
15 Execution plan
Establish boundaries, contracts, then proof of reuse.
The sequence reduces irreversible commitments. It first makes ownership and constraints explicit, then introduces stable contracts, then validates reuse through two controlled adoption paths.
Days 0–30 · Establish boundaries
Approve principles and clarify the current state.
- Inventory AI integrations and direct provider dependencies
- Define use-case intake, risk dimensions, capability taxonomy, and decision rights
- Create the research ledger schema and select initial pilots
Days 31–60 · Establish contracts
Make the governed pathway implementable.
- Implement execution-envelope, identity, rights, policy, audit, and telemetry contracts
- Define model gateway, governed retrieval, evaluation registry, golden paths, and conformance checks
Days 61–90 · Prove reuse
Validate that platform reuse is simpler and safer than independent construction.
- Onboard one internal and one controlled customer-facing candidate
- Measure integration effort, quality, cost, policy behavior, and operational recovery
- Promote proven capabilities and publish architecture version 1.0
16 Red team
Design explicitly against predictable failure modes.
Gateway monolith
Control: Keep orchestration, policy, retrieval, evaluation, and provider adapters independently evolvable behind stable contracts.
Platform slows experimentation
Control: Provide a bounded incubation pathway with temporary exceptions and mandatory evidence capture.
Incomplete rights metadata
Control: Fail closed for consequential external use. Permit approved fallback only for lower-risk internal scenarios.
Governance bottleneck
Control: Encode common approvals as policy and conformance tests. Reserve human review for exceptions and higher consequence.
Protocol participation implies trust
Control: Authenticate every connection, authorize every action, propagate delegated identity, and audit every task handoff.
Evaluation misses workflow value
Control: Connect model and retrieval quality to task completion, user acceptance, operational outcomes, and business metrics.
Research becomes another repository
Control: Store typed evidence, claims, decisions, relationships, ownership, and history. Generate documents from that model.
Maximum maturity becomes the goal
Control: Select maturity by business leverage and risk. Require additional operational complexity to justify itself.
17 Recommendation
Build three coupled products.
The operating architecture works only when delivery, control, and learning evolve together.
The durable platform is the system that allows its technologies to change safely.
It is not one gateway, model router, vector store, graph, agent framework, or protocol. It is the contracts, controls, evidence loops, ownership boundaries, and reusable capabilities connecting them.
AI Capability Platform
Model access, retrieval, tools, orchestration, evaluation, observability, and developer interfaces.
Trust and Control System
Identity, authorization, rights, policy, audit, cost, release pathways, and exceptions.
Evidence and Decision System
Research, claims, evidence, decisions, capability lifecycle, production learning, and publication.
18 Provenance
Primary-source foundation.
This artifact synthesizes the operating model developed in this research thread with official primary guidance. External sources support the framing; NBA-specific recommendations remain architectural analysis.
01NIST AI RMF: Generative AI ProfileRisk profiles, governance, provenance, testing, and lifecycle risk management.
02AWS Well-Architected Agentic AI LensProduction architecture, operations, reliability, cost, and agent-specific workload concerns.
03AWS: Four Security Principles for Agentic AIDeterministic external controls and security boundaries outside probabilistic reasoning.
04CNCF Platform Engineering Maturity ModelPlatforms as sociotechnical products balancing business, people, process, policy, and technology.
05Model Context Protocol SpecificationStandardized connection between AI applications, context, data sources, and tools.
06Agent2Agent ProtocolOpen agent communication and interoperability across independent agent systems.
07OpenTelemetry Semantic ConventionsCommon telemetry semantics and the basis for versioned internal observability mappings.
Methodology note
External documents establish general practices. Recommendations such as the seven-plane model, execution envelope, capability lifecycle, and research ledger are synthesized architecture proposals. They require internal validation against NBA systems, rights policy, security requirements, operating models, and active initiatives.