Process and System Analysis

Overview

The Process and System Analysis framework (T17) handles the case where the user wants a current-state map of how a process, workflow, or system actually works — sequenced steps, actors, decision points, dependencies, bottlenecks, handoffs, and (for feedback-bearing systems) loops with polarity. T17 is descriptive in posture: it documents what is. It does not yet ask why a particular outcome recurs (that is T4, Causal Investigation), and it does not recommend interventions (those belong to evaluation modes downstream). The discipline is to keep the descriptive register clean — prescriptive drift is a known failure mode and the framework’s mode-level evaluators flag it explicitly.

The framework runs three primary modes. Process Mapping handles linear and branching workflows where feedback is not the dominant dynamic — sequenced steps with actor attribution, decision points and branching paths with explicit decision criteria, dependency maps showing what blocks what, bottleneck identification with the underlying constraint named (capacity / authority / information / sequencing — not just the symptom), handoff and friction-point analysis, and the load-bearing distinction between the documented (official) process and the actual (lived) process. Systems Dynamics Structural handles feedback systems where loops, stocks, and flows are the load-bearing structure — variables and stocks with explicit roles (stock, flow, auxiliary, exogenous), feedback loops with polarity verified by parity of negative edges (R for reinforcing, even count of negatives; B for balancing, odd count), explicit declaration of the system boundary so the map does not silently absorb every adjacent variable, marking of delays as first-class elements, and identification of system archetypes (Senge’s eight) only when the matching loop topology is actually present, not as a name-drop. Market Dynamics (added 2026-06-01) handles markets and economic systems, where the operative structure is supply, demand, selection, and competition — both sides of the market modelled with their drivers and elasticity, the equilibrium and the adjustment process that reaches it, the short-run response separated from the long-run response (entry, exit, capacity, substitution), and named economic dynamics (Gresham’s law, diminishing returns, critical mass / network effects, creative destruction, the Red Queen) grounded in an actual mechanism on the market rather than name-dropped; it is descriptive in posture, reading how the market behaves and routing participant advice to decision-architecture (T3) and mechanism or contract design to T18 mechanism-design. The Organizational Structure mode is currently deferred per CR-6.

The framework’s load-bearing intellectual content is the official-vs-actual distinction, the bottleneck-as-constraint discipline, the polarity parity validator, and the archetype-name-drop guard. The official-vs-actual distinction is Process Mapping’s central methodological move — documented processes and lived processes diverge, and a map that conflates them misrepresents how work actually flows; the framework requires both to be surfaced where they differ. The bottleneck-as-constraint discipline refuses to identify a bottleneck merely as the slow step; the underlying constraint that makes the step slow (capacity, authority, information, sequencing) is named, because intervening on the symptom without the constraint reproduces the bottleneck elsewhere. The polarity parity validator is Systems Dynamics Structural’s hard correctness check — declared loops must close (a closing edge in the graph, not a linear chain mis-labeled as a loop), and the declared type (R or B) must match the parity of negative edges. Mis-declared polarity is validator-rejected; the discipline is uncompromising. The archetype-name-drop guard refuses to credit an archetype identification (Fixes That Fail; Tragedy of the Commons; Limits to Growth) unless the matching loop topology is actually present in the declared loops with verified polarity.

The framework’s epistemological posture deliberately resists three patterns that fail process and system mapping. The happy-path flattening where the process is rendered as a single sequence without exception paths and decision branches — counteracted by the explicit decision-points-and-branches requirement. The frictionless-handoff illusion where transitions between actors are treated as costless — counteracted by the handoff-friction examination. Prescriptive drift where the descriptive mapping slips into “what should be done” — counteracted by the descriptive-only discipline at the mode level (T17 is mapping, not intervention).

The framework answers questions like: Walk me through how our deployment process actually runs, including where it deviates from documented. Map the workflow including bottlenecks and what’s causing them. The system keeps oscillating — can you map its feedback structure?

Systemic context

Process and System Analysis sits in the diagnostic-mapping cluster of the Ora analytical-territory architecture. T17 is structurally distinct from T4 (Causal Investigation), which asks why a pattern recurs rather than mapping the current state — the disambiguating question is “why does this keep happening (causes), or how does this currently work (process map)?” — and from T16 (Mechanism Understanding), which explains how parts produce behavior at the principle level rather than the operational level, and from T11 (Relationship Mapping), which surfaces topology without temporal flow. The Decision D parse (2026-05-01 architecture lock) cleanly separated the Systems Dynamics operation into two parsed siblings: T17’s systems-dynamics-structural (mapping the system as it is, including its feedback structure) and T4’s systems-dynamics-causal (using the same feedback lenses to investigate why a recurring pattern occurs). The two modes share the same lens dependencies (feedback-loops; Senge archetypes) but differ in posture and output contract — structural-descriptive vs. causal-investigation. T17 frequently runs upstream of T4 in sequential dispatch: when a causal investigation requires a process map first, T17 runs first; T4 follows. T17 also feeds [[Framework — Decision Clarity Analysis]] when a multi-owner conflict pattern requires the underlying process to be mapped before the decision-clarity analysis can surface the contested ownership.

Ora’s output

Example question: Our customer-onboarding workflow involves five teams (sales, legal, billing, support, customer-success). It works most of the time but stalls unpredictably. Can you map the process as it actually runs and surface the bottlenecks?

Ora’s response (running process-mapping):

The seed names a workflow with multiple actors and an observed problem (unpredictable stalls). T17 mode is process-mapping. The Decision D check confirms this is a process-flow question rather than a feedback-system question (no loops dominating the behavior; the stalls are sequential blockages). I’ll work through the eight required sections.

Process scope and boundaries. Start trigger: signed contract lands in the onboarding queue. End condition: customer-success has confirmed the customer is in active use with first-success criteria met. Excludes pre-sales and long-term account management.

Actor and role inventory. Sales (handoff role; owns the initial package). Legal (reviews contract; flags non-standard clauses). Billing (sets up account; configures payment; sends first invoice). Support (schedules and runs onboarding sessions). Customer Success (owns relationship from active use forward; runs first-success check).

Sequential step breakdown. (1) Sales hands off the contract package to Legal. (2) Legal reviews; signs off; routes to Billing. (3) Billing sets up the account; sends invoice; routes to Support. (4) Support schedules onboarding; runs session; routes to Customer Success. (5) Customer Success makes contact; runs first-success check; declares completion.

Decision points and branches.

DP1 (Legal). Standard contract → fast-track sign-off (1 business day); non-standard → custom handling (5–15 business days). Criterion: clause deviation beyond pre-approved variance.

DP2 (Billing). Standard ACH or card → automated setup (same-day); invoice-with-NET-30 or manual configuration → manual setup (3–5 business days). Criterion: customer’s stated payment method.

DP3 (Support). Customer schedules within 5 business days → fast track; delays → slow track with escalation at the 10-day mark.

Dependency map. Legal blocks all subsequent steps. Billing blocks Support. Support blocks Customer Success.

Bottleneck identification (with constraint named, not just symptom).

Bottleneck 1 — Legal on non-standard contracts. 5–15 day delays. Constraint: authority — only two attorneys authorized to sign off, both heavily allocated. Not throughput capacity; authority bottlenecking through a small number of qualified individuals.

Bottleneck 2 — Customer responsiveness at Support (DP3-slow). Downstream workflow stalls. Constraint: information — customers do not know the session is needed within a specific window because the invitation does not state consequences of delay.

Bottleneck 3 — Billing manual-configuration (DP2-manual). 3–5 day delay stalls Support. Constraint: sequencing — manual configuration could be parallelized with Support’s scheduling, but the workflow treats them as sequential.

Handoff and friction points.

Sales → Legal. The contract package is sometimes incomplete (missing terms summary or contact list); Legal requests the missing information from Sales, adding 1–2 days.

Legal → Billing. Sign-off does not always include the customer’s payment-method preference; Billing asks the customer directly, adding 1–2 days.

Support → Customer Success. First-success criteria are sometimes not communicated cleanly; Customer Success may run the check against criteria the customer was not told about, producing miscommunication-driven failures.

Confidence per finding. High confidence on step sequence and actor attributions. Moderate confidence on bottleneck identifications (constraints inferred from delay patterns; would be confirmed by direct actor interviews). Lower confidence on handoff frictions (anecdotally reported; quantification would require pulling handoff records).

Documented vs. actual. The official documentation describes a 7-business-day timeline assuming standard branches throughout. The actual process runs 7–25 business days depending on branch firings, the upper bound driven by Bottlenecks 1 and 2. The official documentation does not surface the three decision-point branches; it describes only the happy path.

That is what process-mapping produces. The workflow is mapped as it actually runs (not as it is documented); decision points and branches are surfaced explicitly; bottlenecks are identified with the underlying constraint named (not just the symptom); handoffs are examined for friction and information loss; confidence per finding is included so the user knows which parts of the map are firm and which are inferred. The framework produces no recommendations — those would be a different mode (process improvement; organizational redesign).

Commercial AI comparison

Comparison content auto-populates when the comparison-refresh framework runs against this question. Drafters do not author this section.

Brief comparison commentary

Auto-populates with the comparison content above.

How to use this framework

You can run the Process and System Analysis pattern with any AI of your choice. The composition is single-pass for either mode.

The prompt:

[Paste the framework specification]

Run [process-mapping / systems-dynamics-structural].

System or process: [Plain prose description; include actors if known.]

Observed behavior (optional): [What you have noticed; what is going well; what is stalling.]

Documentation (optional): [Any existing process documentation, even if you suspect it is incomplete.]

The AI returns the mode-appropriate output: for process-mapping, eight labeled sections; for systems-dynamics-structural, seven sections including the polarity-verified loop list with R/B IDs and explicit delay markers.

For best results:

1. Disambiguate process-flow vs. feedback-system at the start. If the system’s behavior is dominated by sequential steps with discrete decisions, process-mapping is the right mode. If the behavior is dominated by reinforcing or balancing dynamics (the system oscillates, accelerates, or stabilizes around a setpoint), systems-dynamics-structural is the right mode. The wrong mode wastes effort.

2. Surface the documented-vs-actual gap. When you provide existing documentation, ask the framework explicitly to flag where the actual process diverges. The official-vs-actual distinction is a load-bearing finding in most organizational workflows and the framework should not paper over it.

3. Push for the constraint behind each bottleneck. If the framework identifies a bottleneck without naming the underlying constraint (capacity, authority, information, sequencing), ask explicitly. Constraint-level identification is what makes the map actionable for whoever owns intervention design.

4. For systems-dynamics-structural, verify the polarity parity. The validator is built into the framework, but the user should also count negative edges in any declared loop. Mis-declared polarity is the most common error in feedback-system analysis.

The framework is deliberately tool-agnostic. The official-vs-actual distinction, the bottleneck-as-constraint discipline, and the polarity parity validator are conceptual disciplines that survive the lift to any environment.

Other examples

• Process Mapping on a research workflow. A researcher has a literature-review process spanning search, screening, full-text review, extraction, and synthesis. The framework maps the actual workflow, surfaces the decision points (which abstracts get full-text review), identifies the bottleneck (screening, where the constraint is the researcher’s attention capacity), and surfaces a handoff friction (the citation-management tool loses some metadata between search and screening).

• Systems Dynamics Structural on an engagement loop. A product team notices that user engagement oscillates monthly. The framework maps the feedback structure: an R loop from feature releases producing engagement, a B loop from support-ticket volume reducing engagement when releases produce bugs, and a 1–2 week delay between bug emergence and ticket spike. Polarity parity check confirms the classifications. Limits to Growth archetype is identified because matching topology is present (R bumping against B). Intervention design is a separate mode.

• Process Mapping feeding Causal Investigation. A team’s deployment workflow keeps producing outages. Process-mapping runs first to surface what the workflow actually does (documented version is ten steps; actual is fifteen with three undocumented branches). T4’s root-cause-analysis then runs on the mapped process — the causal investigation operates on the actual workflow rather than on the documented fiction. Canonical T17-then-T4 sequence.

Citations

The Process and System Analysis framework draws on three convergent traditions. The lean / Toyota Production System tradition supplies process mapping’s foundational vocabulary (swim lanes, value-stream mapping, the seven wastes, the official-vs-actual distinction operationalized as gemba walks vs. process documentation). The official-vs-actual discipline is in many ways the lean tradition’s central methodological contribution to operational analysis — work as documented and work as performed are reliably different, and process-improvement that operates on the documentation rather than the reality is not improvement.

The system-dynamics tradition supplies the feedback-loop machinery. Forrester’s Industrial Dynamics (1961) is the foundational text; Sterman’s Business Dynamics (2000) is the standard quantitative reference; Senge’s The Fifth Discipline (1990) is the popularization that introduced the eight system archetypes (Fixes That Fail, Shifting the Burden, Limits to Growth, Eroding Goals, Escalation, Success to the Successful, Tragedy of the Commons, Growth and Underinvestment). Meadows’s Thinking in Systems (2008) and her earlier Leverage Points essay (1999) provide the leverage-point hierarchy used in T17 for transparency only — T17 is descriptive and does not produce intervention recommendations, but the leverage-point vocabulary is named when the structural map enables a downstream intervention discussion.

The polarity parity validator and the archetype-name-drop guard are Ora’s operational disciplines. The polarity parity check (count negative edges; even → R; odd → B) is internal to feedback-loop analysis but rarely formalized as a hard validator; the framework treats mis-declared polarity as a hard failure mode. The archetype-name-drop guard is the discipline against the common practice of naming a Senge archetype because the situation rhymes with it rather than because the matching topology is present in the declared loops.

The framework is at v1.0 (compiled 2026-05-01) with three atomic resident modes (Market Dynamics added 2026-06-01); Organizational Structure deferred per CR-6.

Downloads

• Framework specification (PDF) — link to ora-ai.org canonical artifact when published
• Framework specification (plain text) — link to ora-ai.org canonical artifact when published
• Full white paper (PDF) — link when published