A Prodigal Paradigm productDesign specimen
November 1, 2026
Strategy for
the actual work.
For a fictional regional nonprofit: test AI-assisted intake preparation before changing how decisions are made.
The decision
Authorize discovery of the intake workflow, not deployment. Establish what staff do today, which information is sensitive, and where a draft can be reviewed before it changes anything.
Proposed next move: the operations lead maps one intake process with the people doing the work. The privacy lead defines the data boundary. The sponsor approves a test only after both are explicit.
Non-negotiable: this is not a workforce-reduction plan. No slider setting changes that principle.
What we know - and don't
Scenario assumption: the organization receives repetitive requests and has staff available to review draft summaries. Neither assertion has been verified; both must be established before selecting technology.
Unknown: the current error rate, time spent per case, data sensitivity, existing vendor permissions, and staff capacity to supervise a pilot. No savings or return estimate is defensible until a baseline exists.
The four engines
Four readings of the same organization. Each one has to survive a second reader, and each recommendation names the future outcome it controls. In this specimen the findings are illustrative; in a real document each would carry its source.
Engine one
Ceremony audit
Finding: intake preparation is instrumental. It is judged by whether the right cases reach the right person in time, which is an outcome you can observe. The quarterly program review is ceremonial: it runs because it has always run, and no decision in the past year has turned on it.
The rule: recommendations attach only to the instrumental process. Point an instrumental tool at a ceremonial process and the process absorbs it and produces more ceremony, faster.
What the ceremonial one gets instead: a named question for the management conversation.
Decision consequence: if the classification is wrong, the pilot is pointed at the wrong work and the error shows up as enthusiasm without a changed outcome.
Engine two
Management-decision ledger
Finding: the pilot would free review time before it changes anything else. Freed time stays free only by explicit management decision, so the hours are entered as a decision with an owner and a date rather than described as a saving.
Countercase: the hours may not materialize until the review burden drops, which it will not do in the first cycle.
Dependency: a baseline measured before the pilot starts.
Revisit trigger: the baseline is never established, in which case no capacity claim is defensible and none is made.
Engine three
People arc
Finding: nobody has written down what the intake team does all day, so what hands off and what cannot is unknown. MyRunbook comes before any tool choice; MyWork, the question of what the job is now, comes after people can see their own work on a page.
Constraint: the person who knows why each exception exists is the single point of failure and the single source of the domain knowledge.
Owner: the service lead, not a department.
Acceptance test: four runbooks exist and the exception cases in them are named.
Engine four
Staffing map
Finding: at this stage the weight sits on Builder, Sweeper and Grower. Builder exists in-house and is currently building things nobody asked for, which is a deployment problem, not a talent problem. Grower does not exist, and it is the archetype a stalled pilot is usually missing.
Recommendation: one hire, a grower, not an AI strategist.
Tradeoff: slower start than a contracted strategy engagement, with the capability left inside the building afterward.
Disagreement: engine two would rather fund the baseline first.
Revisit trigger: the builder is given the pilot to own and it moves.
The decision ledger
Each row is a proposed decision in the fictional scenario. “Proposed” and “open” are status labels, not colors.
| Decision | Accountable role | Basis / status | Revisit trigger |
|---|---|---|---|
| Map one intake process before choosing a tool. | Operations lead | Unverified workflow assumption. Proposed. | The process is less repetitive than assumed. |
| Use synthetic inputs for the first technical test. | Privacy lead | Data boundary unreviewed. Proposed. | Real data access is approved or the task cannot be tested synthetically. |
| Retain human approval for every draft. | Service lead | Quality baseline unavailable. Proposed. | Review capacity is inadequate. |
| Agree stop conditions before launch. | Executive sponsor | No thresholds set. Open. | Unacceptable error, data incident, or burden on staff. |
Evidence at the claim
Place the reference beside the statement, not in an unexplained bibliography. Identify external evidence, supplied inputs, assumptions, and analytical judgment separately.
Proposed reference fields: author or organization; document title; publication or version date; section or page locator; URL; retrieval date; support limitation. Print retains actual URLs.
Approval before action
The sponsor should confirm ownership, data boundaries, review capacity, and the baseline before authorizing a pilot. The strategy records unresolved questions rather than quietly answering them.
Still open on this specimen: the fictional inputs stand in for a real organization, and every material claim in a customer document is checked against a primary source before it ships. Rigor outranks the date.