📑 Mục lục bài nghiên cứu
An AI output is rarely the consequence. The consequence appears after someone trusts it, stores it, reuses it, or lets it change a real workflow.
Research lens · Working model · Used in case analysis, stress tests, and operational review
Pathway Lens is the working lens I use to trace that movement from output to reliance, record, action, scale, memory, or real-world consequence. It is not a universal AI-risk framework or a substitute for legal, technical, regulatory, or safety review.
#Core question
What is this AI output, signal, recommendation, or action allowed to become?
The same output may be low-risk as a private draft and high-impact when it becomes an external message, system-of-record entry, decision input, API call, production change, public claim, transaction, or future system memory.
#How I use the lens
- Name the output — What was produced, inferred, recommended, or triggered?
- Trace the pathway — Who or what may trust, reuse, store, scale, or act on it?
- Mark the boundary — Where does it become durable, actionable, authority-bearing, amplified, or difficult to reverse?
- Test the consequence — What evidence, ownership, containment, correction, and recovery are available?
#Supporting tools
01 / Review the pathway
Pathway Governance Starter Kit ↗
Ten questions before an AI pathway enters real workflows, records, tools, or transactions.
02 / Place the controls
Identify where the pathway must remain visible, slowable, stoppable, and recoverable.
03 / Learn and standardize
From Pathways to Operational Standards ↗
Turn recurring incidents and stress-test findings into reusable categories and review standards.
Related inquiry
AI Apprenticeship — Before AI Becomes an Actor
The current working hypothesis asks what AI should learn about mission, boundaries, evidence, exceptions, and recovery before it receives operational authority. It informs the lens but is not part of the 01–03 operating sequence.
Earlier concept lineage: System-Born AI — Inquiry Before Action ↗, preserved as the precursor that led to the apprenticeship formulation.
- Working paper and project history Download Pathway Lens working paper ↗ This page was previously titled Human–AI–System Evolution Framework v0.3. That earlier cycle remains a foundation for how reality, interpretation, coordination, execution, amplification, and new reality interact. Pathway Lens narrows the working object: how an output, signal, recommendation, or agentic action becomes consequence.
#Figure suite
The complete visual suite is available in the Pathway Lens working paper (PDF) ↗. This web edition keeps the lens and its working notes compact.
#1. System Lens
The foundation cycle remains:
Reality → Interpretation → Shared Working / Meaningful Understanding → Coordination → Translation → Execution → Amplification → Outcome → New Reality
This sequence is analytical, not literal. Real systems loop, overlap, and reinterpret. Humans, AI systems, organizations, and institutions repeatedly interpret reality, act on it, change it, and reinterpret the changed reality.
The system lens matters because AI output is rarely consequential by itself. It becomes consequential when it participates in a human, organizational, technical, legal, financial, or social pathway.
#2. Drift Lens
Drift describes a gap between reality, interpretation, shared understanding, coordination, translation, execution, amplification, and the new reality produced by the system.
Drift is not only model error. It may begin before a model is called, after an output is produced, or when operational reality changes faster than governance can update.
Core drift types:
- Reality / Input Boundary Drift — the system receives an incomplete, outdated, distorted, over-narrow, over-broad, or poorly bounded reality-slice.
- Interpretation Drift — humans, AI systems, technical systems, or institutions interpret the same reality-slice differently.
- Shared Understanding Drift — actors appear to coordinate around the same reference but do not share enough meaning, context, or practical understanding to act responsibly.
- Coordination Drift — roles, responsibilities, authority, expectations, escalation paths, or handoffs diverge.
- Translation Drift — meaning changes as it is converted into prompts, fields, tickets, workflows, policies, API calls, code, dashboards, or rules.
- Execution Drift — output becomes action in a way that exceeds authority, evidence, context, or intended use.
- Amplification Drift — local output, action, claim, or interpretation is reused, copied, automated, publicized, scaled, or institutionalized beyond its original context.
- Feedback / Reality Drift — consequences change the reality that later humans, AI systems, or institutions interpret.
Drift is not always harmful. It becomes risky when a system trusts it, stores it, scales it, acts on it, or cannot reverse it in time.
#3. Pathway Lens
The Pathway Lens checks what an AI output, signal, recommendation, or action is allowed to become.
Pathway is the route.
Drift is the distortion.
Variables explain the distortion.
Governance responds to the distortion.
Example output destinations:
- Private draft or personal thinking aid
- Internal note or low-risk summary
- Internal recommendation or decision support
- System-of-record entry or official documentation
- External communication
- Tool / API action or workflow trigger
- Financial, legal, HR, medical, safety, or production consequence
- Future system input, training data, retrieval source, or institutional memory
The same output can have different risk depending on the pathway it enters.
#4. Governance Lens
Governance should be proportionate to the pathway.
The governance lens asks:
- What evidence exists?
- Who or what has authority?
- What action mode is allowed?
- What recovery capacity exists?
- What control capacity is needed?
- What happens when the pathway drifts?
High-impact pathways require stronger evidence, clearer authority, stricter action modes, stronger recovery, and more explicit control capacity.
#5. Evidence
Evidence is not merely stored logs.
Evidence is the ability to reconstruct the pathway: input, prompt, context, output, review, approval, tool call, record change, outcome, incident, and correction.
For multi-agent workflows, evidence should also reconstruct inter-agent causation, delegated tool calls, subagent permissions, and orchestrator ownership.
#6. Authority
Capability is not authority.
An AI system or agent should not automatically inherit the full authority of the human who launched it.
Authority should be bounded through:
- authentication: who or what is acting;
- authorization: what it may do;
- accountability: who answers when consequence occurs.
Authority boundaries matter most when output can become external communication, record change, transaction, production action, legal consequence, or future system input.
#7. Action Modes
Different pathway conditions should trigger different action modes.
Possible modes include:
- observe;
- draft;
- recommend;
- guide;
- constrain;
- require approval;
- act under bounded conditions;
- block or escalate.
The action mode should be chosen by pathway conditions, not by model confidence alone.
#8. Recovery
A system is not governed just because a policy exists.
It is governed only if unsafe or incorrect action can be detected, stopped, contained, reconstructed, corrected, and responsibly restarted.
Recovery includes:
- detection;
- containment;
- stop / shutdown;
- tracing the pathway;
- correction or rollback;
- communication with affected parties;
- review;
- restart approval.
A kill switch is not recovery. Recovery is an architecture.
#9. Control Capacity
Control Capacity is the ability of an AI-enabled pathway to detect, prevent, interrupt, contain, reconstruct, recover from, and safely restart after unsafe or unauthorized AI-enabled action.
It includes:
- agent identity;
- scoped permissions;
- tool and data access boundaries;
- monitoring coverage;
- detection-to-response path;
- evidence preservation;
- rollback or correction capacity;
- containment or shutdown path;
- restart approval;
- inter-agent causation logs.
This concept is a governance refinement, not a replacement for the pathway structure.
#10. AI-Side Support Conditions
AI-side design can support pathway governance, but it does not replace human and institutional responsibility.
Useful support conditions include:
- scoped task design;
- tool permission control;
- context quality;
- output structuring;
- fallback / abstention;
- monitoring hooks;
- version / change control;
- human review fit.
These conditions do not eliminate risk. They make the pathway more observable, constrainable, and recoverable.
#11. AI Starter Kit
The AI Starter Kit is a practical first-pass decision aid for users and teams deciding how to use AI responsibly.
It is included as an AI-assisted practical recommendation synthesis. It is consistent with common recommendations from major general-purpose AI assistants such as ChatGPT, Gemini, Claude, and DeepSeek when asked how users can avoid drifting away from their original goal while using AI.
It should not be treated as external scientific evidence unless the actual model outputs are preserved and cited separately.
Starter questions:
- Do you need AI, or would a simpler rule, workflow, or software automation be enough?
- What happens if the output is wrong?
- Where does the output go?
- What controls are needed before it crosses a boundary?
#12. Pathway-Specific Case Patterns
Scope boundary: Patterns in this section are specific to pathways in which an AI output, signal, recommendation, or action becomes operational consequence. They are not entries in the general Cross-Case Pattern Library ↗. Broader transfer requires separate contextual comparison and explicit promotion.
Case patterns should test whether the lens works in practical settings.
Use this format:
- Pathway: where does the output go?
- Drift: where can distortion appear?
- Boundary: where does operational status change?
- Evidence: what must be reconstructable?
- Authority: who or what is allowed to act?
- Recovery: how can the system detect, contain, correct, or compensate?
- Practical solution: what should be designed or changed?
Example cases:
- customer communication;
- system-of-record update;
- financial transaction or scam prevention;
- code agent or production change;
- multi-agent workflow;
- public narrative or authority signal.
#13. Working principles
- Do not govern every AI output equally. Govern the pathway the output is allowed to enter.
- Do not treat model confidence as authority.
- Do not treat logs as evidence unless the pathway can be reconstructed.
- Do not treat human-in-the-loop as meaningful unless the human has time, context, authority, and responsibility.
- Do not treat recovery as a button. Recovery requires containment, correction, communication, and restart governance.
- Do not let new concepts replace the pathway lens. Reality-slice, meaningful shared understanding, and anchor are diagnostic concepts, not the main pathway spine.
#Status
This page is the updated Notion overview for Pathway Lens. It keeps the original Google Drive link while reframing the project away from a versioned framework and toward the current official working lens.
Further updates should be added as revision notes, source notes, case notes, or appendix updates, not as a replacement structure.
- Underlying pages System-Born AI — Inquiry Before Action · Archived Precursor ↗ Pathway Governance Starter Kit ↗ Practical Boundary Controls Note ↗ From Pathways to Operational Standards ↗