Research / Implementation architecture
How DENFORTH moves from operational evidence to implementation architecture
Enterprise AI becomes useful when operational evidence can be translated into a specific change in work, decisions, systems and accountability. The path is not idea → model → rollout. It is evidence → architecture → bounded implementation → measured operation.
Start with the operating system as it exists
Transformation begins with observed work: where decisions wait, information is reconstructed, handoffs fail, expertise becomes a bottleneck, controls create avoidable load, or people repeatedly compensate for weak systems. The useful evidence is not simply a list of complaints. It is a reconstruction of how work actually moves.
A practical observation frame captures six things together: the trigger, the task or decision, the evidence available at that point, the actors involved, the systems crossed, and the consequence of delay or error. This converts a broad ambition such as “use AI in operations” into an inspectable operating problem.
Evidence becomes a friction model
Observed symptoms need causal structure before technology is selected. A slow approval may be caused by missing evidence, unclear authority, serial handoffs, duplicated controls, poor system integration or genuinely necessary judgement. Each implies a different intervention.
The friction model therefore separates work that should disappear, work that should be simplified, work that can be automated, work AI can augment, and work where human judgement should remain decisive. This is the first architecture decision.
Value
What operating consequence is material enough to change?
Cause
What mechanism produces the friction rather than merely correlates with it?
Boundary
Which workflow, decision, population and systems are actually in scope?
Evidence
What would distinguish improvement from activity?
Move from friction to decision architecture
Many AI opportunities are decision problems in disguise. A decision architecture makes explicit what is being decided, what evidence is required, who has authority, what uncertainty is acceptable, what exceptions matter and what outcome closes the loop.
This matters because an AI component can improve one step while degrading the decision system around it. Faster analysis has little value if approval authority remains ambiguous. Better retrieval does not solve conflicting source definitions. Automated recommendations can increase review load if confidence, provenance and escalation are poorly designed.
Implementation architecture
Design five layers together
Work
Tasks, sequence, handoffs, exceptions and capacity.
Decision
Evidence, judgement, authority, thresholds and escalation.
AI
Model behaviour, retrieval, tools, autonomy and evaluation.
Systems
Data, identity, integrations, permissions, logging and interfaces.
Operating model
Ownership, controls, capability, measurement and learning.
A technically capable model is only one layer. The intervention works when all five layers agree about what the system may do, what humans must do, how evidence moves, how exceptions are handled and who owns the result.
Bound the first implementation
The first build should be large enough to expose the real system and small enough to learn safely. A useful boundary specifies users, workflow, data sources, actions, permissions, decision rights, failure modes and outcome measures before deployment.
This is consistent with the logic of NIST’s AI Risk Management Framework: context is mapped before a go/no-go decision; risks and impacts are measured; responses are managed; governance runs across the lifecycle. NIST explicitly treats contextual knowledge as necessary to decide whether an AI solution is appropriate in the first place.
Workplace evidence points in the same direction. OECD case studies across manufacturing and finance found job reorganisation more prevalent than displacement, while training and worker consultation are associated with better worker outcomes. A 2025 OECD experiment found that consultation could preserve productivity gains while improving job quality. Implementation design is therefore organizational as well as technical.
Build an operating hypothesis, not a demonstration
A prototype proves that something can be made. An operating hypothesis states why a bounded change should improve the system and what evidence would falsify that expectation.
the present workflow loses time and quality reconstructing evidence across fragmented sources,
AI assembles a cited evidence package inside the existing decision boundary,
decision preparation time should fall without increasing material review errors,
cycle time, correction rate, exception rate, reviewer effort and decision outcome.
This structure forces the intervention to carry its measurement architecture from the beginning.
Operate before scaling
Production use exposes what design workshops cannot: edge cases, workarounds, trust calibration, hidden dependencies, new bottlenecks and the actual distribution of human attention. The intervention should therefore enter a learning loop rather than a one-way rollout.
Scale is justified when the operating evidence survives a larger boundary: more users, more variability, more integrations, more consequential actions and higher coordination cost. What scales is not merely the model. It is the complete work system.
The resulting delivery logic
Evidence is converted into an operating capability
Operational reality → friction model → decision architecture → Human–AI allocation → technical + organizational build → measured operation → justified scale.
This sequence keeps research intelligence and implementation connected. Research helps explain what is known, what patterns recur and where assumptions are weak. Operational evidence determines the local problem. Architecture translates both into a system that can be built, used, measured and improved.
Sources
- National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0), 2023; and NIST AI RMF Playbook.
- Milanez, A. The impact of AI on the workplace: Evidence from OECD case studies of AI implementation. OECD, 2023.
- Lane, M., Williams, M. & Broecke, S. The impact of AI on the workplace: Main findings from the OECD AI surveys of employers and workers. OECD, 2023.
- Milanez, A. Exploring win-win outcomes of algorithmic management: Lessons from a laboratory experiment on worker consultation. OECD, 31 July 2025.
From operational evidence to a bounded intervention
The implementation problem is not a linear handoff from discovery to technology. Four architectures must remain aligned as commitment increases.
Figure 01. Implementation architecture. Operational evidence, work and decisions, AI/systems and the operating model evolve together from observation through learning.