F·04 Operational Capture

§ 02

Why operational capture matters

Adopting a platform is not, in itself, a decision to surrender a workflow. A platform may be adopted to make a process faster, more visible, or more collaborative. Over time, the process may be refined, extended, and rebuilt inside the platform. Where the refinements are not documented outside it, the extensions use features only this product offers, and the rebuild assumes its interface, the process becomes increasingly platform-shaped.

At some point, a threshold may be crossed. The organization no longer has a workflow that happens to use a platform. It has a platform that happens to contain a workflow. The process becomes difficult to audit, train, or migrate without the system. Operational Capture describes that threshold.

It can be a quiet form of dependency. No contract renewal or procurement decision necessarily announces it. It can emerge from an accumulation of small adaptations — an automation here, a custom field there — each rational in isolation and collectively difficult to undo. Difficult is not the same as irreversible: documented processes, exportable records and independently defined rules can keep a captured workflow recoverable, even where it has to be rebuilt rather than migrated.

“The organization no longer has a workflow that uses a platform. It has a platform that contains a workflow."

§ 03

The five dimensions of operational capture

Operational Capture is not a single event. It is the composition of several distinct surfaces, each examined through structural questions rather than scores.

D·01

Process Expression

—How is the workflow described inside the organization?
—Is the process expressed in platform-specific constructs?
—Can the workflow be described without naming the product?

D·02

Data Flow Binding

—Where does data enter, transform, and exit?
—Is the data usable outside the platform's export format?
—Are intermediaries or handoffs locked inside the system?

D·03

Participant Roles

—Are roles defined by the platform's permission model?
—Can a participant's function be understood without the tool?
—What happens to the process if platform access is removed?

D·04

Decision Logic

—Where are business rules, conditions, and routing encoded?
—Is decision logic visible outside the platform?
—Can the organization audit or modify rules independently?

D·05

Artifact Ownership

—Who controls the documents, outputs, and records?
—In what format do artifacts exist outside the platform?
—Is there a recoverable source of truth independent of the vendor?

§ 04

What operational capture is not

Operational Capture is frequently confused with adjacent properties that describe different phenomena. It is worth stating the distinctions plainly.

notHigh usage
notUser satisfaction
notIntegration depth
notVendor lock-in by contract
notLegal ownership of the process

A system can be lightly used, neutrally received, and contractually easy to leave — and still have captured an organization's workflow inside its unique structure. Operational Capture is a structural property of how work is expressed, not a measure of enthusiasm or contract terms. Nor does capture mean the platform owns the process: an organization can retain legal ownership of its processes, records and intellectual property while depending on a platform to operate them. Heavy use of a platform is likewise distinct from deep platform-specific process dependence.

§ 05 · Illustrative scenario

The capture progression

An illustrative analytical progression, not an observed or universal lifecycle. Actual trajectories depend on architecture, organizational decisions, available alternatives, documentation and controls. A workflow may stop at any stage, or be moved back towards independent expression.

Phase 01

Tool Adoption

The platform is used alongside existing processes. Workflows still have independent descriptions, documentation, and meaning. The tool is a convenience, not the architecture.

Phase 02

Process Migration

Workflows may be rebuilt inside the platform. The system can become the primary place where work is assigned, tracked, and completed. Outside documentation may begin to lag.

Phase 03

Operational Capture

The process and the platform become difficult to distinguish. The workflow cannot readily be described, audited, or executed without the system. The organization retains legal ownership of its processes and records, and the workflow can still be documented and rebuilt — but not without deliberate work.

Workflow autonomy may decrease →Platform dependence may increase →

§ 06

Conditions worth investigating

Conditions that may indicate deep platform-specific process dependence. They are prompts for investigation, not empirically observed recurring patterns.

Process blindness outside the app
No one inside the organization can describe how work flows without opening the platform. The process exists only in screenshots and interface navigation.
Business logic in automation rules
Conditions, routing, and approval thresholds are encoded as platform automations with no independent documentation or audit trail.
Data enters and never leaves
Information flows into the platform through integrations but exits only in fragmented exports or not at all. The system can become the sole practical custodian.
Roles defined by vendor constructs
Organizational functions are understood through the lens of platform permissions — admin, editor, viewer — rather than independent role definitions.
Documentation is a platform walkthrough
Internal training, onboarding, and procedure documents consist largely of instructions for using the product, not for doing the work independently.

§ 07

How System Drift uses this framework

Operational Capture is one of the primary lenses used across System Drift's published work. It appears, in different forms, in:

ResearchLong-form publications examining how workflows can move from independent processes into platform-native expression.
ProfilesDependency Profiles, currently evidence-pending research shells, list workflow as a surface to examine; no workflow findings are published yet.
ObservatoryDocumented changes, traced to primary sources, to features and automation surfaces that may affect workflow portability.

The framework is descriptive rather than prescriptive. It helps interpret how work is currently expressed; it does not recommend specific tooling or migration strategies. Statements on this page are analytical propositions, not findings from observed organizations; examples and progressions are illustrative scenarios.

§ 08