Service cards
The main user-facing documents. They explain scope, audience, approved use, data guidance, and links to related materials — the layer most people actually read.
Artifacts & relationships
These artifacts are complementary, not duplicative. Each one answers a different governance question — and each connects to the others in a predictable way.
What each document is for
Eight artifact types span the framework, each with a distinct purpose, audience, and place in the stack.
| Artifact | Primary purpose | Main audience | Level |
|---|---|---|---|
| Institutional AI principles | State institutional posture and values | Community, leadership, external stakeholders | Governance |
| Acceptable use guidance | Define allowed and prohibited use | Students, faculty, staff, researchers | Governance |
| AI RMF profiles | Adapt risk management to specific contexts | Governance teams, service owners, reviewers | Profile |
| AI service catalog | List supported tools and entry points | Entire campus | Catalog |
| AI use-case registry | Index approved and proposed uses, mapped to context profiles | Service owners, approvers, governance teams | Catalog |
| AI service cards | Explain what a tool is, for whom, and under what rules | End users, approvers, support teams | Service |
| System cards | Describe the deployed institutional system | Security, privacy, governance, technical owners, auditors | System |
| Model cards / summaries | Describe underlying model capabilities and limits | Reviewers, developers, governance teams | Model |
| Risk and review evidence | Support assurance, approval, and auditability | Internal reviewers and leadership | Evidence |
| Consolidated AI risk registry | Roll up per-deployment risks into one portfolio view | Leadership, governance bodies, auditors | Governance |
How the artifacts connect
A useful rule is to move from broad policy to narrow implementation, and from user-friendly guidance to technical evidence. Three card types do most of the connective work.
System cards
Sit underneath or beside service cards when a service is actually a configured institutional deployment, with architecture, controls, integrations, workflows, and review history — and, for multi-model platforms, the model catalog, routing, and change management that keep them under continuous governance.
Model cards
Sit beneath the system level and describe the actual models used. Sometimes vendor model cards are linked; sometimes internal summaries capture local deployment context.
Each of these artifacts has a blank, fillable template — service card, system card, model card, and the RMF profile above them. Open one, fill it in your browser, and save it as a PDF.
Service card
AI platform
One service users choose from the catalog
Institution-wide
runs on · 1 : 1
System card
Its deployment
One configured system — controls & audit
Restricted Internal
offers · 1 : many
Model cardReasoning modelVendor
Model cardFast modelVendor
Model cardVision modelVendor
Model cardLocal / internal modelInternal
Two governance lanes for shared platforms
An institution-managed platform — one shared service offering several models that users and developers can choose from — is governed along two complementary lanes, continuously rather than once.
Platform governance
The shared service itself: how it is designed, secured, operated, and changed over time — ownership, approved data classes, the model catalog and routing, security controls, logging, and change management.
Mainly Layers 1 · 2 · 5 · 6 · 7
Tool & use governance
What people build on top and how the community may use it: downstream tools, use cases, eligible groups, and the approvals required across teaching, research, administration, and student-facing contexts.
Mainly Layers 2 · 3 · 4 · 7
Continuous, not one-time. Because models, providers, tools, integrations, and allowed uses change over time, a platform is reviewed continuously — its approval is rechecked whenever it changes materially, rather than granted once and left alone.
Rule of thumb
When you are unsure which artifact a thing needs, this test almost always resolves it.
If it is a tool users choose from, create a service card. If it is a configured institutional deployment, add a system card. If it is a specific model or a local model-selection decision, add a model card or internal model summary.
Key terms
A short, neutral vocabulary that keeps language consistent when documenting institution-managed platforms.
Institution-managed AI platform
A shared institutional service that provides one interface to multiple AI models, often with multimodal capabilities and API-enabled extensibility.
Multi-model
The platform offers several underlying models — and sometimes several providers — that users and developers can choose from through the shared service.
Model catalog & routing
The list of enabled models and providers, what each is approved for, and how the platform decides which model handles a request.
Platform governance
Governance of the shared service itself: ownership, controls, the model catalog, logging, and change management.
Tool & use governance
Governance of what people build on the platform and how the community may use it — downstream tools, use cases, eligible groups, and approvals.
Continuous governance
Ongoing review of a production platform, rechecked on every material change rather than approved once.
Material change
Enabling a new model, modality, tool, or integration, or opening a new category of downstream use — each re-triggers review before going live.
Governance boundary
The data classes and use cases a service is approved for — and what is out of scope and where it is routed instead.