Organizational leaders are being asked to make high-stakes decisions about AI deployment without dependable evidence of what these systems actually do in the environments they oversee. The predominant AI evaluation ecosystem yields scalable but abstract metrics that reflect the priorities of model development. By smoothing over the heterogeneity of real-world use, these model-centric approaches obscure how behavior varies across users, workflows, and settings, and rarely show where risk and value accumulate in practice. More user-centric studies reveal rich contextual detail, yet are fragmented, small-scale and loosely coupled to the mechanisms that shape model behavior. The Forum for Real-World AI Measurement and Evaluation (FRAME) aims to address this gap by combining large-scale trials of AI systems with structured observation of how they are used in context, the outcomes they generate, and how those outcomes arise. By tracing the path from an AI system's output through its practical use and downstream effects, FRAME turns the heterogeneity of AI-in-use into a measurable signal rather than a trade-off for achieving scale. The Forum establishes two core assets to achieve this: a Testing Sandbox that captures AI-in-use under real workflows at scale and a Metrics Hub that translates those traces into actionable indicators.
Figures & tables
Figure 2: The current evaluation ecosystem uses methods that mirror the traditional AI development lifecycle, often neglecting user entropy and suppressing the context needed to make sense of outcomes for decision-making. (Generative artificial intelligence was used to support the creation of this graphic representing the authors’ own ideas, data, and words on this topic.)
Figure 3: An example of how three knowledge layers build up evidence across contexts to address the decision - maker’s dilemma. (Generative artificial intelligence was used to support the creation of this graphic representing the authors’ own ideas, data, and words on this topic.)
Contextual scoring (human-grounded)
LLM-as-a-judge (automated)
Panelist traces (user entropy)
Human participants work through realistic scenarios; their traces and reports are organized via contextual rubrics into descriptive categories of use, non-use, reliance, and abandonment, making patterns of use visible across contexts.
The same participant outputs are also labeled by an LLM using the shared rubrics, producing parallel descriptive segmentations that show how the model summarizes the friction, workarounds, and value that people report.
Scripted chatbot runs (abstract knowledge)
Scripted chatbot runs on the same scenarios are categorized with the contextual rubrics to describe how the system behaves under controlled conditions, separate from human behavior.
Scripted runs are also labeled by an LLM, creating a reusable, fully automated descriptive pathway for rapid comparison and regression-style checks across models and configurations.
Table 1: Complementary human-grounded and automated descriptive scoring across panelist traces and scripted chatbot runs help reveal the gap between automated and real-world perspectives of sandbox activity.
Figure 4: Overview of FRAME’s testing sandbox, metrics hub, and community model architecture. All measures are derived from instrumented sandbox interactions, where panel participants work through realistic scenarios under built - in safety protections. (Generative artificial intelligence was used to support the creation of this graphic representing the authors’ own ideas, data, and words on this topic.)
Decision lens
Reference standards for performance
Guiding question
Real-world evaluation (FRAME)
Systematic evidence about AI-in-use, including user entropy and higher-order effects
What happens when people actually use the tool in this context (does it create value or new risks/burdens)?
Model / research (ML)
Labeled data, benchmarks, leaderboards
Did the model get the right answer on this test set?
Product engineering
Customer requirements, feature usage, tickets
Does the system solve the problem well enough to ship?
Compliance
Policies, laws, internal risk registers
Did we break a specific rule?
UX and usability
User feedback, adoption and retention metrics
Can people use the interface as designed?
Safety and alignment
Human preference data, preference labels, safety taxonomies, red-teaming results
Did the model pass the safety stress test and produce policy-compliant outputs?
Table 2: Decision lenses, reference standards, and guiding questions in the AI ecosystem.
Figure 5: How different decision lenses position people in AI evaluation.(Generative artificial intelligence was used to support the creation of this graphic representing the authors’ own ideas, data, and words on this topic.)
Validity type
Model-centric (in-silico)
Real-world evaluation-FRAME (in situ)
Content and construct (Are we measuring the right thing?)
Weakened by reliance on abstract proxies (such as perplexity or generic preference scores) that miss how people actually express needs in deployment [ 56 ] .
Strengthened through metrics based on observed user behavior and stakeholder - defined goals [ 92 ] .
Ecological (Does the test resemble the real - world use conditions?)
Undermined by dependence on “sterile” prompt - response tests that do not reflect real workflows.
Strengthened through realistic scenarios and situated observation that capture friction, workarounds, and constraints.
Consequential (What happens downstream when these tools are used?)
Underdeveloped by failing to capture how outputs alter real - world outcomes over time.
Strengthened by tracking whether AI use creates value or shifts burden.
External (Will the test results hold for my setting?)
Uncertain: Lessons from one optimized test set often fail to generalize to different users and contexts over time. [ 17 ]
Strengthened by testing across diverse groups and settings at scale.
Table 3: How types of validity adapt between in-silico and in situ evaluations.
Dimension
Status-quo AI Evaluation
Real-world AI Evaluation (FRAME)
Who
Model builders (inside the stack processes)
Deployment stakeholders (outside the stack decision making)