Blog · arXiv Analysis · Last reviewed June 25, 2026

The Scaffold Becomes the Capability Gain

The 2026 arXiv paper Comprehensive AI governance requires addressing non-model gains, by Arthur Goemans and ten coauthors, argues that frontier AI governance cannot focus only on the base model. A non-model gain is a capability increase that comes without changing the base model weights: more inference compute, a stronger scaffold, tool access, restricted assets, embodiment, continual learning, or broad diffusion.

The Spiralist lesson is narrow and practical. A scaffold is not decoration around capability. It is the prompts, tools, retrieval, memory, routing, verifiers, agent loops, operators, and workflow glue that can turn the same model into a different governed object.

When the Model Is Not the System

Model-level governance asks what a model can do before release. That question still matters. But the deployed object is rarely just a model. It is a model wrapped in prompts, tools, memory, routing, retrieval, human approvals, cloud quotas, monitoring, domain data, and organizational incentives. The same base model can become a classroom assistant, a coding agent, a cyber workflow, a procurement clerk, or a lab planner depending on the system around it.

Goemans and coauthors name this problem in arXiv:2606.00047. The paper was submitted on May 1, 2026, and the arXiv record says it was accepted to the ICML 2026 position paper track. Its claim is that model-level governance becomes less effective when capability progress is driven by non-model gains: improvements independent from advances in the base model.

For this page, base model means the trained model snapshot before a downstream deployment wrapper changes how it is used. Scaffold means the surrounding machinery that elicits or extends performance: system prompts, task decomposition, retrieval, tools, memory, routers, verifiers, multi-agent loops, human operators, and evaluation or production workflows. Non-model gain means the uplift or risk shift caused by that machinery, by more test-time compute, or by assets the original model developer could not evaluate.

This is close to agent reliability gates, skill manifests, and agent sandboxes, but the emphasis is different. Those pages ask how a particular agent should be bounded. This paper asks where capability actually comes from after the model leaves the lab.

Current Context

As of June 25, 2026, the governance stack already shows why the model boundary is too small. NIST's AI Risk Management Framework is voluntary and aims at risks to individuals, organizations, and society across the design, development, use, and evaluation of AI products, services, and systems. NIST's Generative AI Profile, published in 2024 and updated in 2026, treats generative AI as a lifecycle risk-management problem rather than a single model-score problem.

EU law points in the same direction while still staying mostly at the general-purpose model layer. Article 55 of Regulation (EU) 2024/1689 requires providers of general-purpose AI models with systemic risk to perform state-of-the-art model evaluation, conduct and document adversarial testing, assess and mitigate systemic risks, report serious incidents, and maintain cybersecurity protection. That is a serious model-provider obligation. It does not automatically evaluate every downstream scaffold, customer asset, tool workflow, or inference-budget increase built on top of the model.

Agentic guidance makes the gap more concrete. NIST's 2026 AI Agent Standards Initiative focuses on interoperable protocols, authentication, identity infrastructure, authorization, and agent-specific evaluations. The April 2026 joint guidance Careful adoption of agentic AI services, coauthored by CISA, NSA, ASD's ACSC, the Canadian Centre for Cyber Security, NCSC-NZ, and NCSC-UK, warns that agentic systems combine models with tools, data sources, memory, and planning workflows; it recommends security-minded adoption, least privilege, ongoing visibility, monitoring, human oversight, and avoidance of broad or unrestricted access to sensitive data or critical systems.

Three Non-Model Gains

The paper's taxonomy has three main vectors. Inference gain means capability improvement from scaling compute at test time. More search, longer reasoning, parallel sampling, verification loops, or larger inference budgets can make the same model more capable without changing its weights.

Systems gain means capability improvement from post-training enhancements such as scaffolds, tools, prompt and context engineering, fine-tuning for narrow use cases, routers, verifiers, or multi-agent orchestration. The important governance point is that a scaffold can be a capability artifact. Once a recipe for a useful scaffold circulates, it can spread more easily than a proprietary model.

Asset gain means capability improvement from combining a model with restricted assets not available to the original model developer or tester. The paper gives examples such as government-held expertise, specialized hardware, classified data, undisclosed vulnerabilities, or non-public biological data. The same model can therefore have a different risk profile when placed beside assets the original evaluator could not inspect.

The authors also flag future non-model gains from embodiment, continual learning, and diffusion. Embodiment changes informational capability into physical action. Continual learning can change behavior over the lifecycle. Diffusion can create collective effects when many systems and agents are deployed at scale.

Governance Beyond the Model

The paper does not say model-level governance is obsolete. It says it must be complemented. The listed complements include system governance, entity governance, agent governance, cloud governance, and societal resilience. That portfolio matters because each non-model gain shifts the useful point of control.

System governance watches the deployed application built on top of the model. Entity governance watches the organization: its incentives, risk processes, reporting channels, review structures, and accountability mechanisms. Agent governance focuses on delegation and autonomous interaction, including access boundaries, behavior constraints, deployment restrictions, attribution, and communication protocols. Cloud governance looks at the infrastructure layer, especially where inference scaling itself becomes a capability driver. Societal resilience accepts that some risks may escape technical control and asks how communities recover from disruption.

The governance lesson is uncomfortable but practical. A model card cannot fully certify a downstream system that adds new tools, data, agents, or inference budgets. A capability elicitation result depends on the tested configuration. A pre-deployment evaluation cannot anticipate every scaffold that third parties may build. A release gate that ignores non-model gains can mistake the tested artifact for the deployed one.

Failure Modes

Base-model certification laundering. A provider or buyer points to a base-model evaluation and treats it as approval for a tool-enabled workflow, even though the tool permissions, retrieval corpus, router, memory, or operator loop were not part of the test.

Inference-budget creep. A system quietly receives more retries, longer context, parallel samples, verifier loops, or search depth. The model name stays the same while the practical capability frontier moves.

Scaffold diffusion. A successful agent recipe, prompt chain, workflow template, exploit harness, or lab-planning scaffold spreads faster than the original model release. Governance that only tracks model access misses the transferable system knowledge.

Asset-context jump. A moderate model is placed beside restricted data, privileged credentials, proprietary code, non-public vulnerabilities, procurement authority, laboratory resources, or sensitive records. The risk comes from the pairing, not from the model alone.

Evaluation mismatch. The benchmark tests an isolated chat model while the deployment is a selection system with tools, memory, human escalation, and production logs. This connects directly to the evaluation gap: the unit of evaluation has to match the unit of deployment.

Cloud-control blind spot. If inference scaling is a capability source, cloud quotas, rate limits, logging, customer segmentation, and anomaly detection become governance controls. Treating them as ordinary infrastructure hides a capability lever.

What This Changes

For institutions, non-model gains change procurement and audit. Buying a model API is not the same as buying a governed AI system. The audit question becomes: what uplift comes from the surrounding system, and who is responsible for measuring it? A vendor should disclose tool access, inference budgets, scaffolds, retrieval assets, autonomy level, cloud dependency, and post-deployment monitoring, not only the base model name.

For regulators, non-model gains complicate threshold rules built around model training compute, base-model evaluations, or model release decisions. Those levers remain useful, but the paper argues that capability can emerge after release through inference, systems, assets, embodiment, continual learning, and diffusion. Regulation that never leaves the model boundary will miss some of the places where risk is assembled. Regulation that ignores the model boundary will also fail, because base-model access, weight security, documentation, and systemic-risk duties remain important.

For safety practice, the strongest immediate move is measurement. The paper calls for better metrics for non-model gains, post-deployment monitoring, forecasting methods, and research into governance mechanisms beyond the model level. That is modest language, but it changes the frame: the frontier is not only a model frontier. It is also an integration frontier.

Governance Standard

A serious AI governance record should separate base-model capability from non-model uplift. It should name the model, model version, policy layer, inference budget, scaffold, tool set, retrieval corpus, restricted assets, deployment environment, agent identities, human review points, cloud controls, monitoring obligations, and rollback conditions. It should say which evaluations apply to the base model and which apply only to the full system.

The record should also identify who owns each lever. The model provider may control weights, API policies, and rate limits. The deployer may control prompts, tools, connectors, data, human review, and logging. A cloud provider may control compute quota and anomaly detection. A regulator may see only part of the stack. A useful model or system card should preserve those boundaries rather than compressing them into one reassuring product name.

The record should be revised when the system changes. A new tool, longer inference budget, richer retrieval corpus, additional agent, fine-tune, adapter, new verifier, broader user class, or restricted dataset can be a governance event. Treating those changes as ordinary configuration hides the fact that capability may have moved.

The minimum artifact is a non-model-gain receipt: what changed, which capability or risk could increase, what evaluation covered the changed configuration, what access controls and monitoring apply, who approved the change, and what signal would trigger re-evaluation. That receipt belongs beside safety cases, audit trails, system inventories, and change-management records.

The Spiralist rule is simple: if the scaffold changes what the model can do, the scaffold belongs in the safety case.

Source Discipline

The Goemans paper is a position paper, not a proof that every scaffolded system is dangerous or that every non-model gain should be regulated the same way. Its strongest contribution is the definition and taxonomy: inference gain, systems gain, asset gain, and future pressures from embodiment, continual learning, and diffusion.

NIST sources are governance and standards context, not binding federal AI release law. The AI RMF is explicitly voluntary; the Generative AI Profile is a profile for risk-management practice; the AI Agent Standards Initiative indicates active standards work around agent identity, authentication, authorization, interoperability, and evaluation.

EU Article 55 should be cited carefully. It creates duties for providers of general-purpose AI models with systemic risk, including model evaluation, adversarial testing, systemic-risk mitigation, incident reporting, and cybersecurity protection. It does not by itself certify downstream deployments, customer scaffolds, private datasets, or agent toolchains.

Agentic-AI security guidance is operational guidance. It is useful because it names the same system components that create non-model gains: tools, data sources, memory, planning workflows, privileges, third-party components, logs, monitoring, and human oversight. It should not be treated as proof that a particular agent is safe.

For this topic, source discipline means refusing to collapse four claims into one: what the base model can do, what the scaffold elicits, what restricted assets add, and what the governed deployment actually permits.

Sources

Return to Blog