Lineage and Contributions

Before you rely on Applied Enterprise AI or cite it, you need to see the prior work it builds on. This page names that work and the few things we add.

How to read the credits

Lineage on this page means the prior work an idea builds on, and what Applied Enterprise AI adds to it.

Three verbs carry the credit. We adopt an idea when we take it as it stands. We say we combine or we apply when the parts are other people’s and the combination or the application is ours.

Each combination or application we claim is an original contribution, tagged OC with a number. The numbers are stable, so a missing number is a contribution this site has not explained yet.

We searched published work as of October 11, 2026. The search may have missed earlier work, and later work may say the same thing independently. So we re-check each contribution before an article relies on it.

Durable design and versioned outcome criteria

Durable design anchors work in explicit outcomes, necessary constraints, and evidence. Versioned outcome criteria let each design be judged against a named version.

Builds on

• Cherns, “The Principles of Sociotechnical Design” (Human Relations, 1976): design specifies only what is essential and is never finished.
• Khattab et al., DSPy (2023): uses task signatures and metrics instead of hand-written prompts, and is recompiled for each model.
• Grace, Hadfield, Olivares, and De Jonghe, “Demystifying evals for AI agents” (Anthropic, January 2026): evaluations shape how quickly a team can adopt new models.
• Littlefield (Magnet, July 2026): the task description is the durable part of an instruction.
• Kumar (September 2026): sorting instructions into task descriptions and corrections of model behavior.
• Rotifer Protocol (March 2026): compensatory versus systemic agent engineering.
• Rajasekaran (Anthropic, March 2026): each harness component encodes an assumption about what the model cannot do on its own.
• Shankar et al., “Who Validates the Validators?” (2024): criteria drift, in which people revise evaluation criteria as they see outputs.
• Deloitte (June 29, 2026), McKinsey Quarterly (October 5, 2026), and Kersten, Output to Outcome (July 2026): repeated redesign of the operating model and the work as AI capabilities change. Kersten adds outcome-anchored control of AI agents.
• IBM Institute for Business Value, Redesign for enterprise AI (July 2026): decision rights codified as rigorously as financial controls.

What we add. We combine these ideas into two claims. OC-1: a deliberately versioned basis of outcomes, constraints, and evidence is what keeps repeated redesign of the work system affordable as AI capabilities change. OC-2: the same versioned basis governs decision rights, approvals, and reporting arrangements, not only prompts and evaluations.

Status. Both are hypotheses, and the bounded test proposed for them has not been run.

The two tests of effectiveness, with customer and recipient

The workflow test asks whether a result was acceptable within the boundaries of authorized work. The value-delivery test asks how that result contributed to the customer’s outcome. The second test relies on the difference between customer and recipient.

Builds on

• Kersten, Output to Outcome (2026): output versus outcome metrics, tracing outcome gains to what was delivered, and lagging indicators over a stated timeframe.
• Goldratt, the Theory of Constraints (The Goal, with Jeff Cox, 1984): improving a step that is not the constraint does not improve the system.
• IBM IBV, Redesign for enterprise AI (July 2026): a faster task or workflow produces a business outcome only if the value stream connects it to customer demand.
• Google DORA, 2025 State of AI-assisted Software Development: AI amplifies the strengths and weaknesses of the system around it.
• Guaspari (Quality Digest, 1998) and Cutler (2023): Guaspari critiques the internal-customer model, and Cutler prefers partner to internal customer.
• Applied End-to-End Flow, our sibling framework: finishing a task sooner does not mean the recipient gets usable work sooner.

What we add. We combine these ideas into two tests used together. OC-9 is the explicit pairing, with two features. The workflow test is bounded by authorization as well as quality. The value-delivery test has to ask whether the workflow test’s measures were the right measures. Only after that question does a local result count as customer value.

Status. The tests have been in use on this site since September 2026, and the pairing is a modest contribution.

Three kinds of change

The three kinds of change are acceleration, reconfiguration, and new capability. Two questions tell them apart: did the outcome change, and if not, did the work system change substantially?

Builds on

• Hammer, “Reengineering Work: Don’t Automate, Obliterate” (Harvard Business Review, 1990): redesigning a process rather than automating the existing one.
• Venkatraman, “IT-Enabled Business Transformation” (Sloan Management Review, Winter 1994): levels of transformation from localized exploitation to business scope redefinition.
• BCG, “Turning GenAI Magic into Business Impact” (December 2023): the value plays deploy, reshape, and invent.
• Agrawal, Gans, and Goldfarb, Power and Prediction (2022) and NBER Working Paper 28811 (2021): point, application, and system solutions.
• Henderson and Clark, “Architectural Innovation” (Administrative Science Quarterly, 1990): changing components versus changing how they connect.

What we add. We adopt the three-way distinction. OC-5: we apply an outcome-first test, the two questions asked in that order, with three rules for edge cases. A more accurate result is still acceleration when the steps, interfaces, and decisions around the work are unchanged. A like-for-like substitution of who or what performs a step is acceleration, flagged as substitution. And a redefinition of the outcome has to be declared.

Status. The test is used to classify cases, but neither its consistency across people nor its use for predicting needed changes has been tested.

The work system

The work system is the unit of design. Changes are made at six loci: workflow, task allocation, decision structure, information and feedback, incentives and accountability, and skills. Coordination and governance act through those loci and are not loci of their own.

Builds on

• Alter, “Work System Theory” (Journal of the Association for Information Systems, 2013): the term, and the work system as the unit of analysis.
• Puranam, Alexy, and Reitzig (Academy of Management Review, 2014): every organization solves four problems: task division, task allocation, reward, and information.
• Galbraith, “Organization Design: An Information Processing View” (Interfaces, 1974): organization design as information processing. His later Star Model, in Designing Organizations, names strategy, structure, processes, rewards, and people.
• Neilson, Martin, and Powers, “The Secrets to Successful Strategy Execution” (Harvard Business Review, 2008): decision rights, information, motivators, and structure.
• Brickley, Smith, and Zimmerman (Journal of Applied Corporate Finance, 1995, republished 2020): decision rights, performance evaluation, and rewards.
• Weisbord (Group & Organization Studies, 1976): helpful mechanisms as a cross-cutting element.
• Aghion and Tirole (Journal of Political Economy, 1997): formal versus real authority.
• The Conference Board (September 2026) and Kersten (2026): allocating work to AI alone, people with AI, or people alone.

What we add. OC-6: we combine these ideas into the list of six loci above, with task allocation to people, AI, or automation as a locus of its own. Then we classify each change, not the tool or the whole initiative, by kind and by locus. One initiative can contain several changes, so use of the same tool can be acceleration in one change and reconfiguration in another.

Status. The list and its pairing with kind of change are untested.

Minimum viable redesign and the misleading negative

A minimum viable redesign is the smallest step that contains a capability’s complements, the changes the capability needs in place together.

Builds on

• Milgrom and Roberts (American Economic Review, 1990; Journal of Accounting and Economics, 1995): complementary choices raise each other’s returns.
• Ichniowski, Shaw, and Prennushi (NBER Working Paper 5333, 1995): “adopting individual work practice innovations in isolation has no effect on productivity.”
• Whittington et al. (Organization Science, 1999): piecemeal changes delivered little performance benefit.
• Brynjolfsson, Renshaw, and Van Alstyne, “The Matrix of Change” (Sloan Management Review, 1997), and Athey and Stern (NBER, 1998): mapping how planned changes interact, and testing for complementarity.
• Amis, Slack, and Hinings (Academy of Management Journal, 2004): early change to high-impact elements was necessary, and wide-scale rapid change was not.
• Brynjolfsson, Rock, and Syverson, “The Productivity J-Curve” (2021): early measured returns understate a technology while its complements are being built.
• IBM IBV (July 2026): most executives agreed that AI applied to isolated parts of a workflow delivers limited value unless the process is redesigned.
• The Conference Board (September 2026): redesign and allocate work before deploying agents.
• Kersten (2026): the Commonwealth Bank of Australia’s established operating model let AI productivity gains land while its peers ran pilots.
• In contrast, Little’s Lean Change (2013) defines the minimum as the smallest and least disruptive change that can prove a hypothesis, and Kersten’s shifts can each be applied on their own.

What we add. OC-3: we apply complementarity to the size of a step. The minimum is set by the complements the target capability needs, not by least disruption. The target capability is named before the step is sized. And each step toward that capability states which results should not change yet, because their complements are not in place. OC-4: a pilot smaller than the full set of complements is likely to return a misleading negative, which is a false negative about the capability, not a weak positive.

Status. No validated method yet identifies the set of complements in advance, and OC-4 is untested.

Reviewing AI rules

Reviewing AI Rules separates what a rule serves from how it serves that purpose before the rule changes.

Builds on

• Goldratt, Schragenheim, and Ptak, Necessary But Not Sufficient (2000): which limitation a technology diminishes, and which rules existed to accommodate it.
• Chesterton’s fence: learn why a fence was built before taking it down.
• Hogarth, “Evolving Agentic Engineering at Prisma” (June 2026): compensating instructions can be dropped as the harness improves.
• Rajasekaran, “Harness design for long-running application development” (Anthropic, March 2026): each harness component encodes an assumption about what the model cannot do on its own.

What we add. OC-7: we combine these ideas into one review that separates a rule’s purpose from its method. The review applies the same way to AI instructions and to organizational rules such as approval steps. And it treats a change in AI capability as a reason to inspect a rule, not as the rule’s expiry. The six purposes it checks are listed on the Reviewing AI Rules page.

Status. The review is applied on that page, but it has not been validated as a general method.

Terms we did not coin

Earlier uses we found

• Work system: Alter’s Work System Theory, whose sense this site adapts.
• Minimum viable redesign: Young at Capgemini (June 2016), for website redesign, and Wu at ClarityLab (January 2026), for operating-model change. We use it with our own definition.
• Smallest coherent change: practitioner and software writing in 2026, for example Codes ’n’ Coffee.
• Compensating instructions: Hogarth at Prisma (June 2026).
• Durable, for AI work that survives model change: Khattab’s 2025 talk on AI systems that endure, trade press on durable enterprise AI, and IBM’s “durable design principles” in February 2026.

We claim no coinage for any term on this site, including misleading negative, for which we found no earlier use in this sense.

Sources and lineage

Lineage and Contributions is part of Applied Enterprise AI, a body of work developed by Curtis Hibbs and Joshua Barnes. The contributions tagged OC are proposals to be tested. None has been validated as a general method across enterprises. Prior work was checked on October 11, 2026. If we missed a source or misstated one, tell us on the Applied Enterprise AI LinkedIn page.