View raw markdown

PRISM/AI — AI Architecture Landscape Framework

Version: 1.0
Status: Active
Licence: CC BY-SA 4.0
Family: PRISM Frameworks

§ 1 Overview

AI is now in production across every industry. Organizations have models, agents, RAG pipelines, fine-tuned LLMs, and autonomous workflows — often with no consistent architectural view of what exists, how it's evaluated, whether it's safe, or what breaks when a model drifts.

PRISM/AI is a landscape view of your AI architecture: every model deployed, every AI-powered system built on those models, how they move through lifecycle stages, what trust controls govern them, and what's being measured in production. It covers the full stack from foundation model selection to drift detection.

PRISM/AI is not a training tracker, not a compliance framework, not a model registry. It's the architectural map that connects all of those — committed to git, designed for cross-team visibility, and linked to PRISM/D for data provenance and PRISM/A for application context.

What PRISM/AI replaces (and what it doesn't)

The core assertion

AI architecture has exactly five concerns. Every AI architecture decision maps to one of them.

1. What models exist — model inventory, capability, provenance, deployment target
2. What systems are built on those models — the applications, agents, RAG pipelines, copilots
3. How models move through lifecycle — training, evaluation, deployment, monitoring, deprecation
4. What trust controls govern AI behavior — guardrails, bias assessment, alignment, red-team
5. What's being measured in production — accuracy, latency, drift, override rates, incidents

These five concerns become five dimensions.

§ 2 Foundational Principles

Git-native (Architecture as Code)

Every PRISM/AI landscape lives in a directory committed to source control. A new model version, a guardrail update, a red-team finding — all committed, all traceable. AI architecture decisions are first-class code — this is architecture as code applied to AI systems.

Models are architecture, not experiments

The ML community treats models as experiment outputs. PRISM/AI treats models as architectural assets: versioned, with declared dependencies, serving specific systems, governed by trust controls, and observable in production. A model version is as significant an architectural decision as a database schema.

Trust is non-negotiable and explicit

Every AI system has a trust posture — whether you've documented it or not. PRISM/AI makes trust explicit: accuracy thresholds, bias assessments, explainability requirements, human override availability, and red-team findings are first-class artifacts with enforcement states.

AI behavior assumption type

PRISM/AI recognizes a category of architectural uncertainty that doesn't exist in traditional software: AI behavior assumptions — correctness thresholds, hallucination rates, emergent behavior under distribution shift. These aren't bugs to fix; they're statistical properties to monitor. PRISM/AI's Trust and Observability dimensions provide the vocabulary.

Human-in-the-loop as a declared architectural property

Whether a human must review AI output before it takes effect is an architectural decision, not an implementation detail. human_in_loop is a first-class field on every AI system artifact. Its presence or absence determines deployment risk class and regulatory scope.

Schema version: "1.0"

§ 3 Five Dimensions — The Why

Each dimension answers exactly one question. Together they answer everything about an AI architecture.

Why five, not more?

"Data" is not a sixth dimension — PRISM/D covers training data, feature stores, and data governance. PRISM/AI's Models dimension references the data products from PRISM/D. "Security" is not a sixth dimension — AI-specific security concerns (prompt injection, data extraction, adversarial inputs) belong in the Trust dimension and link to PRISM/CY.

"Cost" is not a sixth dimension — token cost, inference cost, and compute cost are observability signals in the Observability dimension. Adding a Cost dimension would split what is naturally unified monitoring.

Why not fewer?

Four dimensions loses the distinction between Trust and Observability — they address fundamentally different concerns. Trust defines the controls that should hold ("SHAP must be shown to every adjudicator"). Observability measures whether they do ("override rate is 44%, target <40%"). Merging them collapses design intent with empirical measurement.

§ 4 Dimensions and Artifact Types

4.1 Models

The question: What AI models are deployed, and what are they capable of?

The Models dimension is the inventory of every AI model — foundation models, fine-tuned variants, custom-trained models, embedding models, and specialized classifiers — that the organization deploys or depends on.

Key fields:

lifecycle_stage for models:

• research — being explored, not yet in any deployment pipeline
• training — actively being trained or fine-tuned
• evaluation — in eval suite, not yet deployed
• staging — deployed to non-production, acceptance testing
• production — live, serving real traffic
• deprecated — still running, actively being replaced
• retired — decommissioned, no longer running

maturity is a separate axis from lifecycle_stage: lifecycle_stage tracks where the model sits in its deployment pipeline, maturity tracks how disciplined the governance around it is (monitoring, retraining cadence, evaluation rigor) — a production model can still be initial maturity if it ships with no monitoring or retraining process.

4.2 Systems

The question: What AI-powered applications are built on those models?

Systems are the applications, services, and workflows that use models to deliver value to users. A single model can power multiple systems. A system can chain multiple models. The key distinction from PRISM/A: Systems in PRISM/AI are AI-centric — they exist to deliver AI capability, not just to use AI as a component.

Key fields:

4.3 Lifecycle

The question: How do models train, evaluate, deploy, monitor, and retire?

Lifecycle covers the operational processes that move models from research to production and eventually to retirement. These are architecture decisions: retraining cadence, evaluation methodology, deployment strategy, and monitoring frequency directly determine model quality and risk.

Key fields:

4.4 Trust

The question: What controls ensure AI behavior is safe, fair, and aligned?

Trust is the most distinctively AI-native dimension. It covers the controls that constrain, evaluate, and document AI behavior — guardrails, bias assessments, red-team findings, explainability requirements, and alignment controls. Trust artifacts are not optional: every AI system in production must have at least one linked trust artifact.

Key fields:

enforcement levels:

• blocking — model or system cannot deploy/operate if this control fails
• soft-block — output is flagged and routed for human review
• logging — control failure is recorded but does not interrupt flow
• alerting — control failure triggers an alert to on-call
• advisory — recommended, not enforced

4.5 Observability

The question: What is being measured in production, and what has gone wrong?

AI observability goes beyond traditional SRE monitoring. Model accuracy, token cost, hallucination rate, override frequency, demographic drift, and output distribution are all signals that require purpose-built measurement. Observability artifacts declare what's being measured, current values, thresholds, and linked incidents.

Key fields:

§ 5 File Structure

ai-architecture/
└── examples/
    └── acme-insurance/
        ├── .prism-ai/
        │   └── config.yaml          # meta: org, product, temporal_state, as_of
        ├── models/
        │   └── landscape.yaml       # foundation_model, custom_model, embedding_model artifacts
        ├── systems/
        │   └── landscape.yaml       # ai_system, rag_pipeline, copilot, classifier_service
        ├── lifecycle/
        │   └── landscape.yaml       # training_run, eval_suite, deployment, monitoring_job
        ├── trust/
        │   └── landscape.yaml       # guardrail, bias_assessment, red_team_finding, alignment_control
        └── observability/
            └── landscape.yaml       # eval_metric, drift_detector, alert_rule, ai_incident

config.yaml example

prism_ai_version: "1.0"
organization: "ACME, INC"
product: "AI Claims Triage — Architecture Landscape"
domain: insurance
scope: product
temporal_state: transition
as_of: "2025-01-01"
active_dimensions: [models, systems, lifecycle, trust, observability]
ai_risk_class: high           # EU AI Act risk classification
human_in_loop_required: true  # all customer-facing decisions require human review

§ 6 The AI Lifecycle Loop

AI systems don't ship once — they cycle continuously through training, evaluation, deployment, and monitoring.

Research (model selection / prototyping)
    ↓
Training (data → model artifact)
    ↓
Evaluation (eval suite → pass/fail against trust guardrails)
    ↓
Staging (canary / shadow deployment)
    ↓
Production (live serving)
    ↓
Monitoring (accuracy, drift, override rate, incidents)
    ↓
Drift detected or performance degraded
    ↓
Retrain → Evaluation → Staging → Production (loop)

PRISM/AI's depends_on links connect lifecycle artifacts to the models and systems they manage, making blast radius traversal possible: change a training data source → see every downstream eval suite, deployment, and monitoring job at risk.

§ 7 Trust Framework

Trust in PRISM/AI is structured across five types, each addressing a different failure mode:

Risk levels for trust findings:

• critical — immediate deployment block or incident escalation
• high — requires resolution within current sprint
• medium — tracked, scheduled for resolution
• low — acknowledged, accepted or deferred

§ 8 Cross-Referencing

PRISM/AI connects to the broader PRISM framework family:

§ 9 AI-Native Risk Classification

PRISM/AI recognizes five categories of AI-specific architectural risk not found in traditional software:

§ 10 What PRISM/AI Does Not Cover

§ 11 Glossary

Paper

Palakurthi, V.G. (2026). PRISM: Enterprise architecture frameworks for the source-first era.

• Site: https://prism-framework.org/
• PDF: https://prism-framework.org/PRISM_Framework_V1.0.pdf
• SSRN: https://ssrn.com/abstract=7037719
• Zenodo (DOI): https://doi.org/10.5281/zenodo.21325668