That difference may seem linguistic, but it points to a deeper architectural limitation in personal knowledge management systems.
Notes, wikis, and knowledge graphs are generally very good at representing static facts and relatively stable relationships:
Alice works_at Company X.
Feature A depends_on Library B.
Claim C supported_by Paper D.
These representations answer important questions.
Who is connected to whom?
What depends on what?
Which source supports which claim?
Which concept belongs to which project?
But much of practical expertise is not static.
It is procedural.
It takes forms such as:
If this symptom appears, check A first. If A fails, move to B.
Or:
When a quotation request arrives, inspect the drawing, identify the material, estimate machining time, evaluate secondary processing, and only then calculate price.
Or:
If a deployment fails in this particular way, roll back first and inspect the migration state before attempting another deploy.
These are not merely relationships among entities.
They contain order.
Conditions.
Branching.
Failure paths.
Exceptions.
State transitions.
They encode not just what is true, but what should happen next.
And those are different kinds of knowledge.
Knowing what is true and knowing what to do next are different kinds of knowledge.
Knowledge Systems Prefer Nouns
Many digital knowledge systems inherit a document-centric view of information.
A note is an object.
A project is an object.
A person is an object.
A paper is an object.
A claim is an object.
A graph then connects these objects through relations.
This works extremely well for declarative knowledge.
The system can represent that:
Steel has_property high tensile strength.
Service A depends_on Database B.
Experiment X produced_result Y.
But expertise often appears not as an object or a proposition, but as a sequence of actions conditioned on context.
A machinist does not become experienced merely by knowing the definitions of tool wear, workholding, tolerance, material hardness, and cycle time.
A skilled machinist knows:
If the part has this geometry and this tolerance, clamp it this way first, because after the second operation there will no longer be a reliable reference surface.
That knowledge is procedural.
It is not captured simply by connecting:
Geometry related_to Tolerance
or:
Workholding related_to Machining
The value lies in the conditional sequence.
Static Relationships Are Not Enough
Traditional graph structures excel at topology.
They can tell us that objects are connected.
But operational knowledge often requires control flow.
Consider a simplified debugging procedure:
Error detected
→ inspect logs
→ classify failure
→ if network-related, inspect gateway
→ if schema-related, inspect migration
→ if unknown, collect diagnostic state
→ escalate if unresolved
This can certainly be drawn as a graph.
But now the semantics of the edges have changed.
The edge no longer merely means:
A related_to B
It means something closer to:
A must precede B
or:
If condition X holds, transition from A to B
or:
If step C fails, do not continue to D
or:
If state E is uncertain, return to verification
The graph has become procedural.
It is no longer just describing structure.
It is encoding behavior.
That distinction matters because an ordinary semantic graph does not necessarily know whether an edge implies:
association,
causality,
dependency,
sequence,
permission,
transition,
failure recovery,
or execution.
A system can contain all the correct entities and still fail to represent what a competent operator would actually do.
Expertise Often Exists as Conditional Sequence
This becomes obvious in domains where practical competence matters.
Consider manufacturing quotation.
A quotation may look like a pricing problem.
In reality, an experienced estimator may reason through a sequence such as:
inspect the drawing,
identify material,
assess geometry,
determine likely machining operations,
estimate setup complexity,
evaluate tolerance,
check surface treatment,
estimate cycle time,
estimate scrap risk,
account for secondary operations,
calculate margin.
But even this list is too simple.
Real expertise involves branching.
If the tolerance is unusually tight, inspection cost may dominate.
If the part requires heat treatment, dimensional change may alter the machining sequence.
If the stock shape is irregular, fixturing may become the main cost driver.
If surface treatment changes dimensions, final machining may need to happen afterward.
If the quantity is small, setup time dominates.
If the quantity is large, tooling strategy becomes more important.
This is not a static knowledge base.
It is a decision process.
The expert knows not only facts about machining.
The expert knows how facts alter the sequence of decisions.
Debugging Is Also Procedural Knowledge
Software engineering provides an equally clear example.
Suppose a deployment fails.
A static knowledge base might contain:
Deployment depends_on Migration
Migration modifies Database
Application uses Schema
All of this is useful.
But it does not tell the engineer what to do after failure.
An experienced engineer may reason:
First determine whether the application binary deployed successfully.
If the migration failed before commit, inspect the migration state.
If the migration partially committed, do not simply rerun it.
If the application is incompatible with the current schema, roll back the application first.
If the database state is ambiguous, stop automated recovery and inspect manually.
Here, the critical knowledge is not simply the graph of dependencies.
It is the graph of valid actions under different states.
The difference is subtle but fundamental.
A dependency graph explains architecture.
A procedural graph explains response.
Research Workflows Have the Same Problem
Scientific and analytical work also contains large amounts of procedural knowledge.
A researcher's expertise may include:
If the signal disappears after normalization, verify whether the normalization method assumes a distribution that the dataset violates.
Or:
If two datasets disagree, check collection methodology before comparing effect size.
Or:
If an experimental result cannot be reproduced, inspect environment and instrumentation before changing the hypothesis.
These are not merely facts.
They are investigative strategies.
They encode priority.
They encode diagnostic order.
They encode assumptions about where failure is likely to occur.
This kind of knowledge often remains undocumented because it feels obvious to experts.
But it is precisely the kind of knowledge that disappears when experts leave.
The Missing Structure Is Often Control Flow
A conventional graph can represent:
A connected_to B
But procedural knowledge needs richer semantics.
At minimum, it may need to represent:
sequence,
preconditions,
state,
branch conditions,
termination,
retry logic,
exceptions,
rollback,
escalation,
confidence,
and human approval.
This begins to resemble a workflow engine, state machine, or process graph.
That is not accidental.
A procedure is fundamentally about valid state transitions.
Suppose a system can be in states:
healthy
degraded
migration_in_progress
failed
recovered
The correct next action depends on the current state.
An operation that is safe in failed may be unsafe in migration_in_progress.
A retry that is reasonable after a transient failure may be destructive after partial success.
The action cannot be determined from entity relationships alone.
The system needs state-aware logic.
Maybe Some Knowledge Graphs Need to Become Executable Graphs
This suggests a more provocative possibility:
Maybe some "knowledge graphs" need to become executable graphs.
That does not mean every graph should directly control external systems.
Execution can exist at multiple levels.
At the weakest level, the graph can answer:
What is the next valid step?
At another level, it can generate a checklist.
At another, it can track which steps have already completed.
At another, it can recommend actions based on current state.
At another, it can invoke tools with human approval.
And in highly structured domains, some workflows may eventually be automated completely.
The central idea is not autonomous execution.
It is executable semantics.
The graph should contain enough information to determine how knowledge changes action.
That is a much stronger representation than ordinary association.
From Semantic Edges to Transition Edges
Traditional knowledge graphs often prioritize relations such as:
is_a
part_of
works_at
depends_on
supports
contradicts
Procedural graphs require another category of edge:
precedes
requires
branches_to_if
retries_on
fails_to
rolls_back_to
escalates_to
terminates_when
These relations are not merely semantic.
They govern flow.
A node may no longer represent only an entity.
It may represent a state, action, decision, or checkpoint.
For example:
Observe deployment failure
→ Inspect migration state
Then:
Migration state = clean
→ Retry deployment
But:
Migration state = partial
→ Stop automatic retry
Then:
Partial migration
→ Run repair procedure
This is much closer to executable logic than to traditional PKM linking.
Sequence Is Itself Knowledge
One reason procedural knowledge is often underrepresented is that sequence appears trivial.
It is not.
In many domains, order changes meaning.
Consider:
A → B → C
versus:
C → B → A
The same three actions may produce completely different outcomes.
In manufacturing, operation order can determine whether the part can still be clamped.
In database migration, order can determine whether rollback remains possible.
In laboratory work, order can determine contamination risk.
In incident response, restarting a system before collecting logs can destroy evidence.
In security work, remediation before forensic capture can eliminate the information needed to understand the breach.
Sequence is therefore not metadata.
It is part of the knowledge itself.
Conditions Are Knowledge
The same is true for conditions.
Suppose a rule says:
Retry the operation.
That is incomplete knowledge.
A more realistic procedure might say:
Retry only if the failure is transient and the operation is idempotent.
Now the condition contains most of the actual expertise.
Flattening this into:
Failure → Retry
would make the graph simpler.
It would also make it wrong.
Experts constantly reason in conditional form:
Do X unless Y.
Use A if B, except when C.
Normally inspect D first, but if E happened recently, skip directly to F.
The exception often carries more value than the rule.
This is why procedural systems must represent applicability conditions, not merely nominal steps.
Failure Paths Are Knowledge Too
Documentation often focuses on the happy path.
Create.
Configure.
Run.
Validate.
But operational expertise appears in failure handling.
What if step two fails?
What if step three succeeds only partially?
What if the current state cannot be determined?
What if rollback also fails?
What if the procedure is interrupted?
What if two branches happen concurrently?
A mature workflow does not simply describe how success occurs.
It describes how the system behaves under deviation.
For many real-world systems, failure paths are more valuable than the happy path because they capture accumulated experience from previous incidents.
An operational knowledge base that omits failure paths is not preserving expertise.
It is preserving only demonstration.
Exceptions Often Contain the Real Expertise
A novice learns rules.
An expert learns exceptions.
A novice may know:
High latency means inspect the network.
An expert may know:
Usually. But after this type of deployment, inspect database contention first because downstream backpressure often appears as network latency.
The general rule is easy to document.
The exception encodes hard-earned context.
This suggests that procedural PKM should treat exceptions as first-class knowledge.
A robust system may need to store:
default path,
override path,
applicability condition,
priority,
confidence,
provenance,
and last validation date.
Otherwise, a procedural graph can become dangerously rigid.
It would preserve process but lose judgment.
Tacit Knowledge Is Often Procedural
This problem is closely related to tacit knowledge.
Experts frequently struggle to explain why they act in a certain way because their knowledge has become compressed into pattern recognition.
A senior engineer may say:
I usually check this first.
A machinist may say:
That setup just feels wrong.
A researcher may say:
I would not trust that result yet.
These statements sound intuitive.
But underneath them are often years of conditional experience.
The expert has seen combinations of signals that predict particular failure modes.
The challenge for knowledge systems is to externalize that structure.
Not as a vague anecdote.
But as a sequence of observable conditions and decision rules.
In that sense, procedural graphing may be one route toward formalizing tacit expertise.
PKM Could Become a System for Preserving Competence
This changes the purpose of personal knowledge management.
PKM is often framed as a system for storing:
notes,
ideas,
references,
concepts,
quotations,
documents.
That is useful.
But it captures mostly what a person knows.
A richer system could also preserve how a person works.
That includes:
diagnostic routines,
estimation procedures,
decision sequences,
review checklists,
escalation rules,
experimental workflows,
recovery procedures,
quality-control heuristics.
This is not merely personal memory.
It is operational memory.
And operational memory may be far more valuable in professional settings.
A factory could preserve how experienced workers quote unusual parts.
A research lab could preserve how senior researchers investigate inconsistent results.
A software team could preserve how production incidents are triaged.
A designer could preserve review logic.
A writer could preserve continuity checks and revision workflows.
The goal would not simply be to remember information.
It would be to preserve competence.
AI Makes This More Important
The rise of AI assistants makes the distinction even more consequential.
An AI connected to ordinary notes can answer:
What do we know about this?
That is valuable.
But users often ask something else:
What should I do next?
That question requires procedural structure.
Suppose an AI has access to a knowledge graph containing:
Service A depends_on Database B
Migration C modifies Database B
Deployment D includes Migration C
This may help the model explain the architecture.
But when deployment D fails, the model still has to infer the recovery procedure.
If the procedure exists only in scattered prose, the model may reconstruct it differently every time.
It may omit a branch.
It may reorder steps.
It may confuse a rare exception with the default procedure.
It may invent a reasonable-sounding recovery path.
A structured workflow reduces this ambiguity.
The AI can reason over explicit state transitions instead of improvising procedural logic from text.
The Model Should Not Have to Reconstruct the Workflow Every Time
This is a crucial design principle.
If a procedure matters, it should not have to be regenerated from scratch on every query.
Suppose a team has an established incident-response procedure.
Without explicit procedural representation, the model reads documentation and infers:
what matters,
which steps are ordered,
which branches exist,
which exceptions apply,
when escalation is required.
It performs this reconstruction repeatedly.
That is inefficient and difficult to audit.
A procedural graph externalizes those assumptions.
Now the model's task changes.
It no longer needs to invent the workflow.
It needs to map the current situation onto an existing workflow and reason about where the user is within it.
That is a much more constrained problem.
And constrained reasoning is easier to verify.
Procedural Knowledge Needs Provenance
Once procedures become actionable, provenance becomes critical.
For a declarative statement, provenance answers:
Why should I believe this?
For a procedure, provenance must also answer:
Why should I do this?
A workflow step may originate from:
official documentation,
a regulatory rule,
a senior operator,
an incident postmortem,
empirical testing,
company policy,
or AI generation.
These sources are not equivalent.
A good procedural system should therefore know:
who created the procedure,
why it exists,
which environment it applies to,
when it was last tested,
whether it has succeeded previously,
whether it is mandatory or advisory,
and whether it requires approval.
This is particularly important because procedural knowledge decays quickly.
A deployment process may become obsolete after an infrastructure migration.
A manufacturing estimate may change after new tooling is installed.
A research workflow may become invalid after instrumentation changes.
Operational knowledge is highly context-sensitive.
Executable knowledge therefore needs versioning.
Procedures Are Temporal Knowledge
This leads to another distinction.
Many factual relationships are relatively timeless.
Paper A cites Paper B
may remain true indefinitely.
A workflow, by contrast, is often valid only within a specific configuration.
A procedure may apply:
only to version 3,
only before a certain migration,
only to one factory line,
only to one type of customer,
only to one experimental instrument.
This means procedural knowledge has temporal validity.
It must answer not only:
Is this procedure correct?
But:
Is this procedure correct now, in this environment?
A serious operational graph therefore needs context, version, and temporal scope.
The Fundamental Unit May Be the Transition
Traditional PKM treats the note or entity as the basic unit.
A procedural system may need another primitive.
The transition.
A transition can contain:
current state,
preconditions,
trigger,
action,
responsible actor,
expected result,
next state,
branch conditions,
failure behavior,
rollback behavior,
escalation path,
confidence,
provenance.
For example:
Current state: deployment_failed
Precondition:
migration_status = clean
Action:
retry deployment
Expected transition:
deployment_failed → deployment_running
Failure branch:
if retry fails twice → inspect infrastructure
This is much richer than an ordinary relationship.
It is a compact unit of operational reasoning.
Not Everything Should Be Automated
An executable graph does not imply full automation.
Some knowledge should remain advisory.
Some actions require judgment.
Some workflows involve ethics, risk, cost, or irreversible consequences.
A useful system can separate:
informational steps,
recommended steps,
automatable steps,
approval-required steps,
human-only steps.
This distinction matters because procedural representation should increase control, not eliminate it.
The goal is not to replace judgment.
It is to make judgment structurally visible.
From Knowledge Graph to Decision Substrate
Once procedural knowledge is represented explicitly, the graph becomes more than a memory store.
It becomes a decision substrate.
It can support questions such as:
What step are we currently on?
What conditions must be true before continuing?
Which branch applies?
Which action is reversible?
Which failure paths have already been ruled out?
Which previous cases followed a similar sequence?
What should the AI recommend next?
This is a qualitatively different capability from semantic search.
The graph is no longer merely describing the world.
It is helping determine action within the world.
The Larger Opportunity Is Preserving How Experts Think
The most interesting use case may not be better note-taking at all.
It may be preserving expert behavior.
Organizations routinely lose procedural knowledge when experienced people leave.
Documentation often preserves:
terminology,
specifications,
policies,
diagrams,
manuals.
What disappears is:
what experts check first,
which signals they distrust,
which shortcuts are safe,
which shortcuts are dangerous,
when they escalate,
when they stop,
which exceptions matter.
The nouns survive.
The verbs disappear.
A knowledge system capable of representing procedural structure could preserve far more of what makes skilled work skilled.
That would turn PKM from a repository of information into a representation of competence.
Knowing and Doing Are Different
This returns us to the original distinction.
A system may know that:
Feature A depends_on Library B.
It may know that:
Database C stores User D.
It may know that:
Paper E supports Claim F.
But knowing those facts is not the same as knowing:
What should happen when the dependency breaks?
What should be checked first?
What invalidates the usual procedure?
When should the system stop?
What happens after failure?
Those questions require another kind of representation.
They require verbs.
Sequence.
Conditions.
State.
Exceptions.
Recovery.
The next generation of knowledge systems may therefore need to move beyond the idea that knowledge is primarily a set of entities connected by semantic relations.
Some knowledge is better represented as a process.
Some expertise is not a fact.
It is a conditional transition.
And some graphs should not merely describe what exists.
They should describe what can happen next.
Maybe some knowledge graphs need to become executable graphs.
Because knowing what is true and knowing what to do next are different kinds of knowledge.
So a more revealing question for any PKM system is this:
How much of what makes you good at your job could actually be written as nodes and relationships—and how much requires sequence, conditions, failure paths, and exceptions?