# PRO: Turning System Evidence into Governance > Learn how PRO brings policies, risk, and outcomes together to turn system evidence and context into reviewable governance work. Canonical URL: http://modelmonster.ai/docs/governance-approach/pro/ ## Article Metadata - Reading time: 6 min A System Blueprint can show how an AI system is put together, but governance also needs expectations, concerns, and decisions people can review. PRO provides that governance layer. It brings **Policies, Risk, and Outcomes** together so teams can move from understanding a system to deciding what needs attention and what should happen next. ## Build governance on a System Blueprint PRO works on top of CORE, Model Monster's system-blueprint layer. CORE describes the system's Components, Operations, Resources, and Execution flows. PRO applies governance questions to that shared picture and to the business and deployment context around it. ![CORE System Blueprint and Use Case context feeding PRO governance and human review](/media/original_images/visual-1-pro-diagram.png) The two layers answer different questions: - **CORE:** What is in the system? What can each part do and reach? How does information move? - **PRO:** What expectations apply? What could go wrong? What did the review find, and what should happen next? This shared foundation matters. Policies are more useful when they can be applied to a specific system path. Risk discussions are stronger when reviewers can point to system evidence and operating context. Outcomes are easier to explain when they preserve what was examined and why a decision followed. > **Note:** CORE explains what the system is. PRO helps teams decide what governance attention it needs. ## Policies turn expectations into questions Policies describe what is allowed, required, or forbidden. They connect an organization's expectations to the system being governed. For a customer-support AI system, a team might ask: - May customer information reach an external service? - Must answers come from approved support material? - When does a response require human review? - Which Components may access customer records? These questions become meaningful because the System Blueprint shows where information enters, which Components handle it, which Resources are within reach, and where controls or review steps appear. A policy finding is a prompt for review, not the end of the governance process. Reviewers still need to understand the evidence, consider legitimate exceptions, and decide whether the system or the policy needs attention. PRO gives those conversations a consistent structure without pretending that every governance question has a context-free answer. ## Risk organizes what could go wrong Risk is the structured identification and evaluation of failure modes and governance concerns. It helps teams move from a broad sense that "something might go wrong" to a specific concern tied to evidence, context, controls, and ownership. For the customer-support system, relevant concerns might include: - customer information reaching an inappropriate destination - inaccurate or unsupported responses reaching users - an escalation failing to reach a qualified reviewer - insufficient oversight of changes to the system The System Blueprint contributes evidence about the architecture and Execution flows. Policy findings show where expectations may not be met. Use Case context explains who is affected, where the system operates, and how consequential its outputs may be. Reviewers then bring operational knowledge and organizational judgment to the evaluation. Risk is not a single automatically calculated truth. A rating or priority can summarize a judgment, but it cannot replace the evidence and reasoning behind it. PRO keeps the concern connected to the system and the people responsible for deciding how to address it. > **Tip:** A useful Risk record should help another reviewer understand what could happen, why it matters, what evidence supports the concern, and what follow-up is expected. ## Outcomes make governance work reviewable Outcomes are the findings, summaries, records, and other review outputs that result from applying governance logic. They turn analysis into material that people can inspect, discuss, and act on. An Outcome might capture a policy finding, a reviewer decision, a mitigation that still needs work, a risk summary, or information prepared for reporting. Together, these records can help teams: - see which issues need attention - preserve what was reviewed and decided - explain decisions across legal, compliance, risk, security, engineering, and leadership teams - identify owners and next actions - revisit the analysis when the system or its context changes Exact output names and statuses may differ across product surfaces. The stable concept is that Outcomes make governance work visible and reviewable. They are not final legal determinations, and their existence does not by itself establish compliance. ## Add the context architecture cannot show A System Blueprint can reveal a great deal about structure and flow, but architecture cannot answer every governance question. Use Case context captures facts such as the system's purpose, its users and affected people, its sector and deployment jurisdiction, its degree of autonomy, and whether it makes or informs consequential decisions. It can also describe operating conditions that are difficult to infer from connections alone. This context can change how the same architecture should be governed. A support assistant that suggests help-center articles presents a different decision context from a system that makes or informs decisions about employment, credit, healthcare, or access to essential services. The Components might look similar while the applicable Policies, Risks, and required review differ substantially. Use Case is not a fourth PRO pillar. It is contextual input that helps teams apply all three pillars appropriately. ## See PRO applied to one system Return to the customer-support System Blueprint: a chat interface sends a request to a model, the model uses an approved retrieval source, customer records may be available through a CRM, activity is logged, and some conversations can move to a human escalation path. ![Customer-support System Blueprint moving through PRO review to Outcomes and human follow-up](/media/original_images/visual-2-example-cycle.png) PRO gives the team a connected review cycle: 1. **Apply Policies.** Ask whether customer data may reach each destination, whether the model uses approved information, and which situations require escalation. 2. **Evaluate Risk.** Organize concerns such as inappropriate disclosure, inaccurate responses, weak escalation, or insufficient oversight. Consider the blueprint, Policy findings, existing controls, and the system's operating context. 3. **Produce Outcomes.** Record findings, reviewer decisions, mitigation needs, owners, and summaries for follow-up or reporting. 4. **Review and act.** Qualified people examine the Outcomes, confirm that the evidence reflects the system, and decide what needs to change, be accepted, or be monitored. The pillars reinforce one another. Policies make expectations explicit. Risk connects concerns to evidence and context. Outcomes preserve the result of the review and give the team a place to continue the work. Human follow-up turns that structure into accountable governance. > **Tip:** Ask four questions: What rule applies? What could go wrong? What did the review find? What happens next? ## Use PRO to support accountable governance PRO can support framework-aligned governance and compliance work by connecting system evidence and Use Case context to Policies, Risk, findings, and records. This can help teams work with the NIST AI Risk Management Framework (NIST AI RMF), ISO 42001, the EU AI Act, the General Data Protection Regulation (GDPR), the California Consumer Privacy Act (CCPA), and other governance contexts. PRO makes that work more consistent and easier to revisit. Teams can use it to review evidence, explain decisions, identify concrete follow-up, and return to the analysis when a system, policy, or operating context changes. It supports those decisions, but it does not certify compliance, determine legal obligations on its own, or replace qualified legal counsel and organizational judgment. *This article is for informational purposes only and does not constitute legal advice. Regulatory requirements vary by jurisdiction, industry, and specific circumstances. Consult qualified legal counsel for guidance specific to your organization.* ## Next steps - [Understand CORE](/docs/governance-approach/core/) to learn how the System Blueprint gives PRO its foundation. - [Map CORE+PRO to governance frameworks](/docs/governance-approach/mapping-core-pro-to-existing-governance-frameworks/) to compare this model with established approaches. - [Create and manage Policies](/docs/risk-identification-and-management/creating-and-managing-policies/) to move from the concept to policy workflows. - [Add Use Case context](/docs/risk-identification-and-management/use-case-context/) to document business, deployment, and regulatory facts architecture cannot show. - [Build your Risk registry](/docs/tutorials/building-your-risk-registry/) to organize the concerns your organization reviews.