1.Introduction

Most institutions did not adopt AI through a single decision. Tools arrived through procurement, vendor suites, research computing, and features switched on inside existing systems. The documentation that should accompany those tools — who owns them, what data they may handle, what risks they carry — tends to be scattered or missing entirely.

This framework gives that documentation a single, layered structure. It moves from broad institutional policy down to specific models, and from user-friendly guidance toward technical evidence. Each layer answers a narrower question than the one above it, and every artifact carries an explicit audience and visibility label so that publishing decisions are deliberate rather than accidental.

2.The documentation hierarchy

The framework is organized as seven layers, narrowing from institution-wide rules to the evidence behind a single deployment.

3.Core artifacts

The artifacts are complementary, not duplicative — each answers a different governance question. Three card types do most of the connective work:

• Service cards are the main user-facing documents, explaining scope, audience, approved use, and data guidance.
• System cards sit beneath or beside service cards when a service is a configured institutional deployment. For a multi-model platform, the system card also records the model catalog, routing logic, and change management — making model selection a documented governance decision rather than a configuration detail.
• Model cards sit below the system level and describe the actual models used, whether vendor-published or internally summarized.

Around these sit institutional principles, acceptable-use guidance, RMF profiles, the service catalog, and the supporting evidence layer — each with a defined owner, audience, and visibility.

4.How artifacts relate

A simple rule keeps the hierarchy coherent as it grows: move from broad policy to narrow implementation, and from user-friendly guidance to technical evidence.

A shared institution-managed platform — one service offering several models that users and developers can choose from — is governed along two complementary lanes, continuously rather than once:

• Platform governance covers the shared service itself: 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 covers what people build on top and how the community may use it: downstream tools, use cases, eligible groups, and required approvals (mainly layers 2, 3, 4, 7).

Each lane has an institutional index at layer 3. The service catalog records the services on offer; a parallel use-case registry records the uses the community is approved for or has requested. A use case is mapped against the relevant context profile to decide approval, and if it hardens into a configured deployment it graduates into its own service or system card.

5.Implementation types

The same framework documents very different categories of AI offerings, each tending to require a particular combination of artifacts.

Institution-managed platforms with several selectable models, APIs, and extensible tools warrant the most attention here: they require both platform governance and tool/use governance, kept under continuous review as models, modalities, and integrations change. A sandbox is one mode of such a platform — an experimentation space governed by the same system card — rather than a separate implementation type.

6.NIST AI RMF profiles

The middle of the stack is anchored by profiles built on the NIST AI Risk Management Framework. The framework's four functions — Govern, Map, Measure, Manage — are voluntary and not specific to higher education, but they can be tailored into profiles for particular contexts: teaching and learning, research, administration, student engagement, procurement, and agentic or cloud AI.

Profiles turn a general risk framework into context-specific guidance and govern how services in each setting are reviewed and approved. Full profiles are typically internal; a public summary communicates the expectations that apply to each setting.

Layer 2 carries two kinds of profile, matching the two governance lanes: context profiles (teaching and learning, research, administration, student engagement) that govern how AI is used, and platform profiles for institution-managed platforms, cloud AI, or agentic systems that govern the shared service itself.

7.Visibility & publication policy

Not every document should be public. Each artifact carries one of four visibility labels, so transparency means disclosing the right thing to the right audience — not publishing everything.

Sensible defaults follow: publish user guidance, keep control evidence internal, treat model documentation as mixed-visibility, and publish summaries when full documents are too sensitive.

8.Operating model

A lightweight operating model keeps the framework maintainable. Every artifact opens with a short metadata header — title, document type, primary audience, visibility, owner, approver, version, and review date — and moves through a five-step review:

1. Author proposes the document type and visibility.
2. Service owner confirms scope and intended audience.
3. Privacy, security, and governance reviewers validate the visibility choice.
4. Approver confirms publication location and access controls.
5. Visibility is rechecked whenever the service changes materially.

9.Adoption & peer context

The framework is not speculative. Peers commonly publish AI principles, acceptable-use and academic-integrity guidance, tool catalogs, and vendor model-card links. Less common — and where this framework adds the most — are formal RMF profiles by domain, reusable service-card templates, system cards for institution-run deployments, and unified visibility rules across all artifacts. The framework assembles existing practice into a more complete institutional model.

10.Conclusion

Adopted together, these layers let the campus community understand what AI exists and how to use it, while giving reviewers and auditors enough internal evidence to assess risk, controls, and accountability. It is both a transparency framework and a governance operating model — a registry of the institution's AI, documented once and disclosed appropriately.

A.Key terms

A short, neutral vocabulary for documenting institution-managed platforms.