The scaling laws are the most boring part of the frontier. Add compute, add data, add parameters, and capability rises along a curve that has held across several orders of magnitude. What is not boring is the second derivative. The interval between meaningful capability doublings has been getting shorter, which means the curve everyone fixates on is not the dangerous one. The dangerous one is the curve of the rate itself.
Most enterprise planning treats the frontier as a level. A model is chosen, an architecture is fit to its capabilities, a roadmap is drawn against what it can do today. That plan is correct on the day it ships and wrong shortly after, because the thing it was fit to has moved. The error is not in any single decision. It is in the assumption that the frontier is a fixed point you can build against, when it is a moving point whose speed is increasing.
§ 01 / THE CURVEA known input, a steeper output
The scaling relationship is, by frontier standards, well understood. Capability improves as a predictable function of compute, data, and parameter count. None of those three is the surprise. The surprise is what happens when you stop measuring the input and start measuring the calendar. The compute thrown at frontier training has been growing faster than linearly, the efficiency of converting that compute into capability has been improving in parallel, and the two compound. The output curve is therefore steeper than the input curve that drives it.
This is why benchmarking a model against last year's model understates the situation. The gap is not constant from year to year. A capability that took two years to double once takes less than two years the next time, because both the resources and the techniques that produce it are themselves improving. The curve does not just go up. It goes up at an increasing rate.
The frontier is not a level you build against. It is a moving point whose speed is increasing, and most roadmaps are fit to where it stood.
§ 02 / THE SECOND DERIVATIVEWhy the rate is the thing that matters
A firm that plans against the level of capability is solving the wrong equation. It asks what the best model can do and designs an operating model to exploit exactly that. The design is sound until the next release, at which point the assumptions baked into it are stale and the firm is running on a frontier that no longer exists. It has, in effect, hard-coded a capability level into its architecture. Every contract that names a vendor, every workflow that assumes a fixed accuracy, every interface that speaks one model's dialect is a place where the level was frozen.
When the doubling time was constant, this would still hurt, but you could amortize the cost of re-fitting over a predictable interval. When the doubling time is itself shrinking, the re-fitting interval shrinks with it. The firm is re-obsoleted faster than it can re-plan. The cost of being tuned to a fixed frontier is not a one-time write-down. It is a recurring tax that grows as the rate grows.
The consequence is counterintuitive and it is the whole point. The advantage does not go to the firm that picks the best current model. It goes to the firm whose architecture is indifferent to which model is best, because that firm absorbs each step of the curve without re-planning. Frontier capability is, to a first approximation, available to everyone on roughly the same schedule. What is not available to everyone is an operating runtime that can take delivery of it.
We do not ask a client which model they have standardized on. We ask how long it would take to swap it.
If the answer is measured in quarters, the architecture has hard-coded the frontier, and the frontier is the one thing guaranteed to move.
§ 03 / THE ABSORPTION LIMITThe gap is where the discipline lives
There is the curve the labs produce, and there is the curve a given firm can absorb. The first is set by physics and capital and is roughly common to the industry. The second is set entirely by the firm's own architecture, and it varies enormously. The distance between the two is the only number that matters operationally, because capability the firm cannot absorb is capability that lands on a competitor's balance sheet instead.
Closing that gap is not a modelling problem and it is not a procurement problem. It is a runtime problem. The same disciplines that let a firm ship one model are the disciplines that let it absorb the next ten: closed feedback loops that re-evaluate continuously rather than at launch, data contracts that are versioned and SLA-enforced so a new model can be wired in without renegotiating the boundary, decision rights stated explicitly so authority does not have to be relitigated each time the system improves, and human review kept off the critical path so the loop stays fast enough to learn. A runtime built this way treats a frontier step as an input it was designed to receive, not an event it has to recover from.
Build for the curve, not the point
Concretely, an architecture that absorbs a moving frontier shares a small set of properties. None of them is exotic. All of them are routinely skipped under the pressure to ship against today's model.
- Model-agnostic interfaces. The system speaks to capability through a boundary, not to a named vendor. Swapping the model behind the boundary is a configuration change, not a project.
- Standing re-evaluation. Every model in production is scored continuously against live outcomes, so the moment a better one clears the bar, the switch is evidence-driven rather than political.
- Contracts that name no capability level. Data and decision contracts specify the shape of the exchange, not the accuracy of the thing producing it, so a better model raises the ceiling without breaking the agreement.
- Humans off the critical path. Review sits beside the loop as audit and escalation, never inside it as a gate, so improvements in capability translate directly into improvements in throughput.
A firm with these properties does not need to predict the frontier. It does not need to know how short the next doubling time will be. It needs only to be the kind of system that takes delivery of whatever arrives, on whatever schedule it arrives. That is the durable position, and it is an architecture, not a forecast. The forecast is someone else's job and it keeps being beaten anyway.
You cannot out-predict a shrinking doubling time. You can only build a runtime that does not need the prediction.
The frontier will keep moving and it will keep accelerating, and no roadmap fit to a single point on that curve survives contact with the next one. The deliverable is not a model selection and it is not a deck. It is a runtime engineered to absorb a frontier that refuses to hold still, and that work is what closes the gap between the curve and what your firm can actually use. The methodology is where that runtime gets built; the assessment is where we measure how far your current architecture sits from the curve.
END