Skip to content

Technology Architecture Framework

Why AI Platform Architecture Matters Now

Most enterprises did not set out to build an AI platform. They set out to solve individual problems. A customer service team integrated a chatbot. A product team added a copilot. An engineer connected a business process to a model API over a weekend. Each experiment was rational in isolation. Collectively, they produced something no one intended: a sprawl of point solutions, redundant subscriptions, disconnected embedding pipelines, and business units spinning up their own models against their own API keys with no central visibility into cost, performance, or risk.

This is not a hypothetical. McKinsey's 2025 State of AI survey found that 88% of organizations now use AI in at least one business function (McKinsey, 2025) — but adoption has not been matched by consolidation. The data on the financial side is telling: as of the 2025 FinOps Foundation survey, 63% of organizations were tracking or managing AI spend, up sharply from 31% the year before — which means more than a third still could not account for what they spent on AI (FinOps Foundation, 2025). When most of an organization's AI usage is unattributed, there is no way to aggregate cost, enforce policy, or catch a runaway agent before the invoice arrives.

The cost of point-solution sprawl is not only financial. It is architectural. An enterprise cannot audit what it cannot see, cannot govern what it did not provision, and cannot optimize what it has no unified view of. When every team routes its prompts through a different API key, there is no way to aggregate cost, enforce policy, or catch a runaway agent before the invoice arrives. When every team selects its own models, there is no shared evaluation, no compliance review, and no mechanism to retire a model that turns out to be unsuitable.

88% of organizations now use AI in at least one business function (McKinsey, 2025), yet as of 2025 only 63% of organizations were managing their AI spend — up from 31% a year earlier (FinOps Foundation, 2025). Centralized cost attribution remains the exception, not the rule.

This consolidation gap shows up in the maturity data as well. Only about 21% of organizations report having a mature model for governing autonomous AI agents (Deloitte, 2026), and the organizations that pull ahead tend to be the ones that centralize: "future-built" firms are roughly three times as likely to operate a central, integrated AI platform as their lagging peers (BCG, 2025). Centralization is not bureaucratic overhead — it is the pattern that correlates with capturing value.

This track defines the platform layer that makes everything else work. AI Governance & Risk sets policy — which models are approved, what data handling is permissible, what human review is required. Data Readiness manages the inputs — data quality, pipelines, lineage. The platform layer provides the shared engineering layer that makes both operational: the API gateway through which governed models are accessed, the model registry that enforces compliance classifications, the observability infrastructure that gives governance and data teams visibility into what is actually running.

Without the platform layer, governance is a document and data readiness is a project. With it, both become enforceable, auditable, and improvable over time.

What the AI Platform Layer Owns

The AI platform layer is not the same as the ML engineering team that builds models, and it is not the same as the IT infrastructure team that manages compute. It is the function that owns the shared services on which all AI development in the enterprise depends — the APIs, registries, orchestration infrastructure, and observability tooling that individual teams build on rather than rebuild for themselves.

The scope of the AI platform layer covers five domains:

API gateway and cost governance. The platform layer owns the single controlled access point through which teams reach external model APIs — OpenAI, Anthropic, Google Gemini, and open-source inference endpoints. Centralized access enables unified cost visibility (spending by team, by use case, by model), rate limiting (preventing a runaway agent or an overbudget experiment from consuming the organization's API allocation), and audit logging (a complete record of what prompts went to which models and when, which is required by both governance frameworks and, increasingly, regulation). Without centralization at the API layer, none of these controls are possible. See API Governance and Cost Control for implementation patterns.

Model registry and selection. The platform layer maintains a shared catalog of approved models — the set of models that have been evaluated, classified for compliance purposes, and approved for use in production. Each registry entry captures the model's capabilities, benchmark performance on task types relevant to the organization, cost profile, data residency and training data provenance, EU AI Act classification, and the use cases it is approved for. The registry is the operational bridge between governance policy and engineering practice: governance approves which models are permissible; the registry makes those decisions accessible to teams at the point of selection.

Orchestration and agent infrastructure. When teams build LLM-powered applications — chains, agents, retrieval-augmented generation pipelines, multi-step workflows — they need shared infrastructure to do it on. The platform layer owns the shared orchestration runtime, prompt management system, caching layer, and agent execution environment. Shared orchestration infrastructure means teams are not re-implementing the same patterns independently, and it means the platform team has visibility into how the infrastructure is being used. See the tooling landscape overview for the current state of the framework and runtime ecosystem, and MCP and the Context Gap for what the Model Context Protocol specifically standardizes for connecting agents to tools and data, and what it deliberately leaves for the platform team to build.

Developer enablement. The best platform is one that makes the right thing the easy thing. Developer enablement means SDKs, internal APIs, prompt templates, starter kits, and integration patterns that let product and engineering teams build on approved infrastructure without re-solving solved problems. A team integrating a RAG pipeline should be starting from a working template, not a blank file. A team choosing a model should be consulting a registry with evaluations already done, not conducting their own evaluation from scratch.

Observability and cost reporting. The platform layer owns the unified dashboard that shows API spend by team and model, latency distributions by use case, error rates, and cache hit rates. Observability is not optional — it is the mechanism by which every other platform function is validated. Cost reporting is the primary tool for accountability and for identifying where platform investment (caching, batching, model substitution) pays off.

Model Selection and Evaluation

Choosing a model is not a one-time decision, and it is not a vendor preference. It is an engineering decision made against a specific set of requirements, and it should be made with evidence. The market reinforces the point that this is a live, shifting decision: enterprise LLM spending is no longer concentrated in a single provider. By 2025, Anthropic had reached an estimated 40% of enterprise LLM spend, OpenAI 27%, and Google 21%, a sharp reordering from OpenAI's roughly 50% share in 2023 (Menlo Ventures, 2025). A model selection process anchored to one vendor's roadmap is a process that will be wrong within a year.

The relevant dimensions for model selection vary by use case, but the framework is consistent:

Capability. Does the model perform well enough on the specific task type? Public benchmark scores are useful signals but rarely sufficient — and several once-standard benchmarks (notably MMLU) are now largely saturated near the top of the leaderboard, which limits their power to discriminate between frontier models. Capability evaluation must use a representative sample of real production prompts (or a representative proxy), with human evaluation or automated evaluation against ground-truth outputs. A model that scores highest on general benchmarks may underperform on the organization's specific domain vocabulary, document formats, or reasoning requirements.

Cost. Per-token or per-call costs must be evaluated at expected volume, not at prototype scale. A model that is affordable at 10,000 calls per day becomes a significant budget item at 10 million. Cost modeling should include input tokens, output tokens, caching discounts, and the cost of any fine-tuning or retrieval infrastructure. The cheapest capable model for a given task is usually the right model, but "cheapest" must be evaluated over the actual usage profile, not the pricing page.

Latency. Interactive use cases (copilots, chatbots, real-time assistance tools) have hard latency requirements. The classic human-factors thresholds still hold: roughly one second is the limit for keeping a user's flow of thought uninterrupted, and around ten seconds is the limit for holding their attention on a task without a progress indicator (Nielsen, Response Times: The 3 Important Limits, Nielsen Norman Group). On the web specifically, Google found that 53% of mobile site visits are abandoned when a page takes longer than three seconds to load (Google, 2016) — a useful reminder that latency tolerance for interactive AI is measured in low single-digit seconds, not tens. Batch processing use cases (document processing, nightly enrichment pipelines) have effectively no latency constraint. Model selection must account for this: the fastest model is not always the most capable, and the most capable model is not always fast enough.

Compliance. Data residency requirements (does processed data leave the EU?), training data provenance (was the model trained on data that creates IP or privacy exposure?), and EU AI Act classification (is this a high-risk AI system under Annex III?) all constrain the set of permissible models. These are not post-hoc considerations — they are first-pass filters that determine which models are eligible before capability evaluation begins.

Vendor risk. Model providers vary substantially in their contractual posture on model change notification, data handling, SLA commitments, and lock-in exposure. The risk is concrete: when OpenAI retired its first-generation GPT-3 models, it set a hard shutdown date of January 4, 2024, forcing every dependent application to migrate (OpenAI, Deprecations). Provider notice windows can be as short as two weeks for preview models. A model that is excellent today and changes materially without notice creates a governance and performance risk. Vendor risk assessment for model selection follows the same framework as vendor risk in AI governance — contractual protections, notification rights, and auditability all matter.

The build vs. fine-tune vs. API decision. Most organizations should start with foundation model APIs and move toward customization only when the evidence supports it — and the data shows this is what they actually do. Around 72% of enterprises access their model through an API rather than self-hosting (a16z, 2024), and only about 9% of production models in enterprise use are fine-tuned (Menlo Ventures, 2024). The decision logic:

  • Use a foundation model API when the task is within the model's general capability, latency and cost are acceptable at target volume, and the use case does not require knowledge or behavior that cannot be conveyed in the prompt or retrieved via RAG. This is the right default for most enterprise AI applications, and it is what the large majority of enterprises do.
  • Consider fine-tuning when a task type requires consistent formatting, tone, or domain-specific behavior that cannot be reliably achieved through prompting; when the volume is high enough that fine-tuned efficiency gains pay for the tuning cost; or when prompting a large model is too slow or expensive for the use case. Fine-tuning on task structure and format is commonly worthwhile; fine-tuning to inject knowledge (as opposed to using RAG) is usually not.
  • Consider open-source or self-hosted models when data must not leave the enterprise perimeter, when volume is so high that API costs exceed the cost of running infrastructure, when the use case requires a model size that runs efficiently on commodity hardware, or when the enterprise has a genuine need to inspect and modify model weights. Over a quarter of enterprises self-host at least some models (a16z, 2024), and open-weight models have become a mainstream option rather than a fringe one.
  • Build a specialized model only when the enterprise has a truly distinctive data asset or task structure that no available model — fine-tuned or otherwise — can address, and when the organization has the ML engineering capability to sustain a model development program. This is rare and expensive; most "we should build our own" instincts are better served by fine-tuning or retrieval augmentation.

Document every model selection decision: the use case, the evaluation set, the models evaluated, the scores on each dimension, and the rationale for the choice made. Model selection documentation is both a governance artifact and an institutional asset — it prevents the same evaluation from being repeated in six months.

API Governance and Cost Control

Without centralized API governance, costs balloon invisibly. The bill arrives at the end of the month and no one can explain which team, which application, or which experiment generated which portion of the spend. By the time an explanation is assembled, another month has passed. This is the default state of the more than one-third of organizations that still do not track AI spend at all (FinOps Foundation, The State of FinOps 2025).

The alternative is an API gateway pattern: a single controlled access point that all AI API traffic routes through before reaching the upstream model provider. The gateway handles authentication (teams get gateway credentials, not provider credentials), logging (every request is recorded with team, use case, model, token counts, and cost), budget enforcement (spending limits by team and use case, with alerts before limits are reached), and rate limiting (preventing runaway agents or misfired loops from consuming the quota).

Implementation patterns for cost control:

Prompt caching. Major providers offer prompt caching at significant discounts on repeated input. Anthropic prices cache reads at 0.1× the base input token cost — a 90% discount on cached tokens — with cache writes at 1.25× base input for the five-minute tier (Anthropic, 2026). OpenAI applies caching automatically to prompts of 1,024 tokens or longer, with the discount on cached input ranging from 50% on its earlier model generations to as much as 90% on its newest models (OpenAI, 2026). For applications with large, stable prefixes (long instruction sets, reference documents, few-shot examples), caching the static prefix can cut input token costs substantially: an independent academic benchmark across OpenAI, Anthropic, and Google models measured 41–80% total API cost reductions on long-horizon agentic tasks (Lumer et al., 2026), versus the "up to 90%" figure that providers cite as a best-case ceiling. The platform layer should implement caching by default for all prompts with static prefixes above the trigger length, rather than leaving caching decisions to individual application teams — and it should ensure dynamic content is never placed inside the cached prefix, which silently defeats the cache.

Model tiering and routing. Not every query requires the most capable (and most expensive) model. A routing layer that sends simple, well-defined queries to a smaller, cheaper model and reserves the frontier model for complex or ambiguous queries can reduce cost substantially with minimal quality impact. The platform layer owns the routing logic; individual teams define the complexity threshold for their use case.

Batch processing. Anthropic and OpenAI both offer batch APIs at a 50% discount on both input and output tokens for non-real-time workloads, with turnaround typically under an hour (Anthropic, 2026) or within 24 hours (OpenAI, 2026); Google's Gemini Batch API applies the same 50% discount (Google, 2026). Document processing, nightly enrichment, bulk classification, and evaluation runs are all candidates for batch processing. The platform layer should expose a batch queue as a first-class service, making it trivially easy for teams to route eligible workloads to the batch endpoint.

Usage budgets and alerts. Every team and every use case should have a defined monthly budget, with alerts at 70% and 90% of budget before the limit is reached. The platform layer owns the budget tracking and alerting infrastructure. Alerts go to both the team lead and the platform team — cost overruns are a signal of either a runaway process or a use case that has scaled faster than anticipated and needs infrastructure review.

Request logging for audit. Every request through the API gateway must be logged: timestamp, team, use case, model, input tokens, output tokens, cost, response latency, and whether the request hit cache. Logs serve three purposes: cost attribution (accurate billing back to teams), compliance audit (proof that governed models were used for governed use cases), and performance analysis (identifying which use cases are bottlenecked on latency or where cache hit rates could be improved).

Build vs. Buy vs. Partner

The most consequential platform architecture decision is not which model to use or which orchestration framework to adopt. It is the meta-decision of what to build, what to buy, and what to partner for — applied layer by layer, not answered once for the whole platform. The market has swung decisively toward buying: by 2025, roughly 76% of enterprise AI use cases were purchased from vendors rather than built in-house, a reversal from the near-even 47%-build / 53%-buy split a year earlier (Menlo Ventures, 2025). The pendulum swings, which is exactly why a default answer is dangerous.

Most organizations get this wrong by defaulting to one answer. "We buy everything" leaves the enterprise dependent on off-the-shelf solutions that encode other organizations' integration assumptions and cannot be tailored. "We build everything" consumes engineering capacity on infrastructure that commodity vendors build better and faster, and distracts from the institutional knowledge that actually differentiates the enterprise.

The right framework is tiered:

Layer Decision Rationale Examples
Commodity infrastructure Buy or use managed services No differentiation in owning this; off-the-shelf solutions are better-maintained and more capable than anything an enterprise would build Foundation model APIs, vector databases (Pinecone, Weaviate, pgvector), embedding services, managed inference (Vertex AI, Bedrock, Azure OpenAI Service)
Integration and orchestration Build integration logic on top of bought/open-source components; own the integration patterns The glue between commodity components is specific to the enterprise's data model, process, and security requirements; own this layer Internal API gateway configuration, routing logic, prompt management system, RAG pipeline architecture, cost attribution logic
Strategic capability Build what encodes institutional knowledge; own and maintain This is what actually differentiates the enterprise — the prompts, fine-tuned behaviors, and retrieval corpora that reflect institutional expertise Fine-tuned models trained on proprietary data, prompt libraries encoding domain expertise, evaluation sets built from institutional knowledge, custom agents that automate proprietary workflows

The practical implication: invest in buying robust commodity infrastructure, build opinionated integration and orchestration on top of it, and apply genuine engineering investment to strategic capability. A large language model is not a strategic capability; the prompts and retrieval corpora that make it behave like a domain expert at your organization usually are.

See the practitioner guide to designing an AI platform function for worked examples of applying this framework.

Platform Governance and the Build-Out Sequence

Order matters. Organizations that try to build the full AI platform at once produce a partially-complete platform with no component working well enough to drive adoption. The sequence below is not the only viable order, but it reflects where most enterprises get early value and where dependencies are real.

Stage 1: Centralized API access and cost visibility. Stand up the API gateway first. This produces immediate value (cost visibility, rate limiting, audit logging) and creates the foundation for every subsequent stage. It is also the easiest stage to justify: the cost savings from preventing runaway experiments and enabling caching typically pay for the gateway infrastructure within one or two billing cycles. Every model API call in the organization should route through the gateway before any other platform work begins.

Stage 2: Model registry and evaluation capability. Build a shared catalog of approved models with their capability classifications and compliance status. Stand up a lightweight evaluation infrastructure — a harness for running representative prompts against candidate models and comparing outputs. The registry does not need to be sophisticated; a well-maintained shared document is better than a complex system no one updates. The evaluation harness does need to be repeatable — model selection decisions should be reproducible, not dependent on individual memory.

Stage 3: Shared orchestration infrastructure. Once teams have an approved set of models to work with and a gateway to access them through, build the shared orchestration layer — the prompt management system, caching layer, and agent runtime that teams build on. Do not build this until Stage 1 and Stage 2 are stable; teams building on unstable infrastructure produce systems that fail in ways that are hard to attribute.

Stage 4: Developer enablement. Once the platform is stable, invest in making it easy to use: documentation, starter kits, reference implementations, office hours, and onboarding support. Developer enablement is what converts a platform into an organization-wide capability — without it, the platform is used only by the teams that helped build it.

Avoiding premature standardization. Do not mandate a single orchestration framework organization-wide before the use cases are understood. This is not a theoretical risk: the orchestration market reshapes itself yearly. LangChain and LangGraph only reached their 1.0 releases in late 2025; Microsoft folded AutoGen and Semantic Kernel into a single successor framework; and OpenAI deprecated its Assistants API in favor of a new Responses API. An org-wide mandate locked in before these shifts would have aged badly. Let early use cases inform platform decisions rather than locking the platform before the use cases are known. The platform team should hold off on hard framework mandates for at least the first six to twelve months of production operation.

Platform governance. The AI platform is shared infrastructure. Changes to it — new models in the registry, changes to the gateway configuration, updates to the orchestration framework, pricing changes in the cost allocation model — affect every team that depends on it. Platform governance defines how changes are proposed, tested, communicated, and rolled back if needed. At minimum: a change log accessible to all consuming teams, advance notice (not same-day) for changes that affect API contracts or cost attribution, and a rollback procedure for any change to the gateway or routing configuration.

Common Failure Modes

Tool sprawl. Each team picks its own AI stack. One team uses LangChain, another LlamaIndex, a third has built custom orchestration. Each team manages its own API key, its own embedding pipeline, its own vector store. There is no shared cost visibility, no shared model registry, and no mechanism to enforce governance policy. Sprawl compounds over time — the more independently each team operates, the harder it is to consolidate, and the more expensive any consolidation becomes. The antidote is establishing the API gateway and model registry early, before sprawl becomes entrenched.

Premature platform lock-in. The platform team selects one orchestration framework and mandates it across the organization before production use cases are established. Six months later, the framework turns out to be poorly suited to the most important use case class, or the vendor pivots, or a clearly superior alternative emerges. Unwinding an org-wide framework mandate is expensive and disruptive. Platform standardization decisions should be made deliberately and late — after enough production experience to understand the actual requirements.

Shadow AI infrastructure. Business units or engineers route around the approved platform because it is too slow, too restricted, or too bureaucratic. The scale of this is well documented — 78% of AI users report bringing their own AI tools to work (Microsoft & LinkedIn, 2024), and shadow AI is now a measurable security exposure: one in five breached organizations attributed the breach in part to shadow AI, and high shadow-AI usage added roughly $670,000 to the average breach cost (IBM, 2025). Shadow AI infrastructure is a signal that the platform is not meeting teams' needs — it should be treated as feedback, not only as a compliance violation. The response is to make the platform faster and easier to use, not merely to add restrictions that get routed around even more creatively.

Governance theater. A shared API gateway exists, a model registry has been created, and the documentation is comprehensive. But no one checks the cost attribution reports. The model registry has not been updated in four months. The gateway logs are stored but never reviewed. The evaluation process is documented but teams skip it when they are under time pressure. Governance theater in platform architecture has the same root cause as governance theater everywhere else: the platform team is measured on shipping the platform, not on the platform being used and maintained. Active governance requires active maintenance — someone must own the registry, review the cost reports, and follow up when teams bypass the evaluation process.

Platform Architecture Checklist

  • [ ] All AI API traffic (external model providers) routes through a centralized API gateway — no team-managed API keys in production
  • [ ] Cost attribution is active: API spend is tracked by team, use case, and model, and reported at least monthly
  • [ ] Spending budgets and alerts are configured for every team and use case, with alerts before limits are reached
  • [ ] A model registry exists, is actively maintained, and covers all models approved for production use including compliance classifications and EU AI Act tier
  • [ ] Prompt caching is enabled for all prompts with large static prefixes; batch processing is used for eligible non-real-time workloads
  • [ ] A model evaluation harness is in place; model selection decisions are documented with the evaluation set, scores, and rationale
  • [ ] Shared orchestration infrastructure is available for teams to build on, with reference implementations and starter kits
  • [ ] Developer documentation covers how to access the API gateway, use the model registry, deploy on shared orchestration, and submit model evaluation requests
  • [ ] An observability dashboard is active showing API spend, latency distributions, error rates, and cache hit rates across the platform
  • [ ] A platform change management process is defined: advance notice to consuming teams, change log, and rollback procedure

Assess your organization's current platform maturity against the platform maturity scoring assessment. For the governance framework that defines policy the platform must enforce, see AI Governance & Risk.

Sources

  • McKinsey — The State of AI, 2025. 88% of respondents report regular AI use in at least one business function, compared with 78% a year ago. View source · verified 2026-06-20 · primary
  • FinOps Foundation — The State of FinOps, 2025. AI spending is now managed by the majority of respondents (63% up from 31% last year). View source · verified 2026-06-20 · primary
  • Deloitte — State of AI in the Enterprise 2026 (Agentic AI is scaling faster than guardrails), 2026. By 2027, 74% of respondents expect their companies to be using AI agents at least moderately, but only 21% say their organizations have a mature governance model in place for agentic AI. View source · verified 2026-06-21 · primary
  • BCG — The Widening AI Value Gap (Build for the Future 2025 Global Study, n=1,250), 2025. 3x More central AI platforms in operation to enable scale and adoption. View source · verified 2026-06-21 · primary
  • Menlo Ventures — State of Generative AI in the Enterprise, 2025. We estimate Anthropic now earns 40% of enterprise LLM spend ... OpenAI lost nearly half of its enterprise share, falling to 27% from 50% in 2023. View source · verified 2026-06-21 · primary
  • Google — The Need for Mobile Speed, 2016. 53% of mobile site visits are abandoned if pages take longer than 3 seconds to load. View source · verified 2026-06-21 · primary
  • Andreessen Horowitz (a16z) — 16 Changes to the Way Enterprises Are Building and Buying Generative AI, 2024. 72% of enterprises who use an API to access their model ... over a quarter of respondents did self-host, likely in order to run open source models. View source · verified 2026-06-21 · primary
  • Menlo Ventures — State of Generative AI in the Enterprise, 2024. only 9% of production models are fine-tuned. View source · verified 2026-06-21 · primary
  • Anthropic — Prompt caching (Claude Developer Docs), 2026. 5-minute cache write tokens are 1.25 times the base input tokens price; 1-hour cache write tokens are 2 times the base input tokens price; Cache read tokens are 0.1 times the base input tokens price. View source · verified 2026-06-21 · primary
  • OpenAI — Prompt caching (OpenAI API guide); Prompt Caching in the API (launch announcement), 2026. API calls to supported models will automatically benefit from Prompt Caching on prompts longer than 1,024 tokens ... reduce ... input token costs by up to 90%. View source · verified 2026-06-21 · primary
  • Lumer et al. — Don't Break the Cache: An Evaluation of Prompt Caching for Long-Horizon Agentic Tasks (arXiv:2601.06007), 2026. caching reduced API costs 41-80% and improved time-to-first-token 13-31%. View source · verified 2026-06-21 · primary
  • Anthropic — Batch processing (Message Batches API, Claude Developer Docs), 2026. most batches finishing in less than 1 hour while reducing costs by 50% and increasing throughput. View source · verified 2026-06-21 · primary
  • OpenAI — Batch API guide (OpenAI API), 2026. 50% cost discount compared to synchronous APIs; Each batch completes within 24 hours (and often more quickly). View source · verified 2026-06-21 · primary
  • Google — Batch Mode (Gemini API docs), 2026. The Gemini Batch API is designed to process large volumes of requests asynchronously at 50% of the standard cost. View source · verified 2026-06-21 · primary
  • Menlo Ventures — State of Generative AI in the Enterprise, 2025. Today, 76% of AI use cases are purchased rather than built internally. ... 47% of AI solutions were built internally, 53% purchased. View source · verified 2026-06-21 · primary
  • Microsoft & LinkedIn — 2024 Work Trend Index Annual Report, 2024. 78% of AI users are bringing their own AI tools to work (BYOAI). View source · verified 2026-06-20 · primary
  • IBM — Cost of a Data Breach Report, 2025. having a high level of shadow AI ... added an extra USD 670,000 to the global average breach cost ... Shadow AI ... was a factor in 20% of breaches (2025 global average breach cost fell 9% to USD 4.44 million). View source · verified 2026-06-21 · primary