#Pragmatic Utility & Value Alignment

Pattern E.13 · Stable Part E - The FPF Constitution and Authoring Guides

The FPF provides a powerful engine for constructing formally correct and highly reliable holons. This power, however, introduces a subtle but profound risk: a team can create a perfectly verified and validated artifact (AssuranceLevel:L2) that solves an irrelevant, misunderstood, or non-existent problem. The framework guarantees that the solution is correct, but it does not, by itself, guarantee that the solution is useful.

#Keywords

• pragmatic
• utility
• value
• Goodhart's Law
• Proxy-Audit Loop
• MVE.

#Relations

#Content

#Problem Frame

The FPF provides a powerful engine for constructing formally correct and highly reliable holons. This power, however, introduces a subtle but profound risk: a team can create a perfectly verified and validated artifact (AssuranceLevel:L2) that solves an irrelevant, misunderstood, or non-existent problem. The framework guarantees that the solution is correct, but it does not, by itself, guarantee that the solution is useful.

Furthermore, many of the most important system objectives—such as "safety," "usability," or "security"—are not directly measurable. They are assessed via proxy characteristics (e.g., "number of reported vulnerabilities" as a proxy for security). This practice is vulnerable to Goodhart's Law: when a proxy becomes the primary target, it often ceases to be a good measure of the original goal, as teams begin to optimize the proxy at the expense of the real objective.

#Problem

Without a formal mechanism to keep the entire assurance apparatus tethered to real-world value, FPF risks enabling two critical failure modes:

1. Formalism for Formality's Sake: Teams become preoccupied with achieving high epistemic scores, producing elegant but useless artifacts. The framework is used to build beautiful solutions to the wrong problems.
2. Proxy-Metric Distortion (Goodhart's Law): Teams successfully optimize for a chosen proxy characteristic, but in doing so, they diverge from—or even actively undermine—the true, often qualitative, U.Objective that the proxy was intended to represent. The system becomes technically successful but pragmatically a failure.

#Forces

#Solution

FPF elevates Pragmatic Utility (Pillar P-7) to a normative architectural principle, operationalized through two mandatory conceptual mechanisms.

#The Principle of Pragmatic Utility (Expanded Definition)

Any artifact created within the FPF is an instrument for achieving a specific, pragmatic U.Objective. The value of an artifact is determined solely by its utility in achieving that objective, not by its epistemic scores in isolation.

#Mechanism 1: The Proxy-Audit Loop

To formally manage the risk of Goodhart's Law, FPF introduces a conceptual feedback loop to periodically review the alignment between proxy characteristics and their intended goals.

• New Normative Relation: A new relation, isProxyFor: U.Characteristic → U.Objective, is introduced. This relation MUST be used to explicitly declare when a measurable characteristic is serving as a proxy for a higher-level, often qualitative, goal.
• Conceptual Audit Process: Any characteristic marked with the isProxyFor relation is subject to a periodic conceptual audit.
• Review Roles: This audit is conceptually performed by the individual(s) in the Strategist role. They are tasked with answering the question: "Is optimizing for this proxy still reliably driving progress toward the actual U.Objective it represents, or have we observed a divergence?"
• Output Concept: If a divergence is identified, a high-priority U.Method for revising or replacing the proxy MUST be proposed.

Didactic Note for Managers: Are You Climbing the Right Mountain?

The Proxy-Audit Loop is your compass. Your team's dashboards might show all green—metrics are improving, targets are being hit. But the audit loop forces a crucial question: "Are these the right metrics?"

Imagine you are trying to improve "customer satisfaction" (U.Objective). You choose "average call handle time" as a proxy metric. Your team successfully drives this number down. But the Proxy-Audit reveals that customer satisfaction is actually decreasing because agents are rushing and providing poor service to meet the time target. The loop forces you to recognize this divergence and find a better proxy (e.g., "first-call resolution rate"). It ensures your team is not just climbing fast, but climbing the right mountain.

#Mechanism 2: The Minimally Viable Example (MVE) Mandate

To enforce a pragmatic, value-first approach from the very beginning of a project, any new U.System or major system component MUST begin its development cycle with the creation of a Minimally Viable Example (MVE).

• Definition: An MVE is a simple, end-to-end, working instance of the holon that demonstrates the achievement of at least one core, user-facing objective, however trivial. It is the FPF equivalent of a "Hello, World" for a complex system.
• Assurance Requirement: The MVE MUST achieve a minimum of AssuranceLevel:L1 (Substantiated). This means the MVE cannot be a mere mock-up or a purely conceptual sketch; it must be supported by at least one piece of tangible evidence (e.g., a passing test case, a formal assertion), as defined in Pattern B.3.3.
• Stege transition Precedence: The development of the full-scale holon cannot proceed to AssuranceLevel:L2 until the MVE has been created and has met its L1 requirement.

#Conformance Checklist

• CC-E13.1 (Proxy Declaration Mandate): Any U.Characteristic used as a primary driver for an objective MUST be explicitly linked to that U.Objective via the isProxyFor relation.
• CC-E13.2 (Proxy-Audit Mandate): A formal Proxy-Audit review MUST be conducted at regular conceptual intervals (e.g., before each major release). The outcome of this review MUST be a documented episteme.
• CC-E13.3 (MVE Mandate): The development of any new U.System MUST be preceded by the creation of an MVE that satisfies the AssuranceLevel:L1 requirement.
• CC-E13.4 (MVE Traceability): The full-scale U.System MUST maintain a formal traceability link (isEvolutionOf) to its originating MVE.

#Common Anti-Patterns and How to Avoid Them

#Consequences

#Rationale

This pattern operationalizes Pragmatic Utility (P-7). While Pattern E.12 protects the agent from the cognitive overload of the framework, this pattern protects the problem from being lost in a sea of formal abstraction. It provides the necessary constitutional guardrails to keep the powerful formal methods of FPF focused on delivering tangible, real-world value.

The MVE Mandate ensures that every journey starts with a destination in sight. The Proxy-Audit Loop ensures that the compass used on that journey remains pointed in the right direction. Together, these mechanisms guarantee that knowledge generated within FPF is not only formally correct and epistemically reliable, but also meaningful, useful, and aligned with its intended purpose.

#Relations

• Implements: Pillar P-7 Pragmatic Utility.
• Complements: E.12 Didactic Primacy & Cognitive Ergonomics.
• Provides context for: The definition of U.Objective and U.Characteristic by establishing a formal link between them.

#E.13:End