The Hogan and the Highway: Comparing Traditional Provenance to Digital Workflow Topologies

Every carrier network engineer has felt the pull between two worlds. One is the world of the hogan: a structure built from relationships, cycles, and deep contextual knowledge passed between shifts. The other is the highway: a layered, standardized topology where traffic flows through predictable interchanges and every packet's provenance is logged in a structured schema. This guide compares these two approaches to workflow provenance—not to declare a winner, but to help you decide when each makes sense for your carrier topology.

Where Provenance Models Meet Real Work

In a typical carrier operations center, the tension between traditional and digital provenance shows up during every major outage. The senior engineer who has run the same metro ring for fifteen years can tell you exactly which splice case failed last summer and which vendor's transceiver historically drifts at high temperatures. That knowledge is a form of provenance—it tracks the lineage of decisions and events. But it lives in one person's head, not in a database.

Meanwhile, the digital workflow topology that the NOC team has adopted tracks every configuration change, every alarm correlation, and every ticket escalation through a directed acyclic graph. It produces beautiful dashboards. But when the senior engineer retires, the graph alone cannot explain why that particular protection path was chosen over another in 2017, or why the backup generator at that hut has a history of failing during monsoon season.

This is not a niche problem. In carrier networks—where fiber cuts, power failures, and hardware degradation are daily realities—the cost of incomplete provenance shows up as extended mean-time-to-repair (MTTR) and repeated troubleshooting cycles. Teams that rely entirely on digital workflow topologies often find themselves rebuilding context from logs after a turnover. Teams that rely entirely on oral tradition lose institutional memory when people leave.

We have seen projects where a new automation platform was deployed to replace a legacy manual process, only to have the operations team keep a parallel spreadsheet because the digital topology didn't capture the "why" behind certain routing decisions. The spreadsheet was the hogan; the automation platform was the highway. Both were necessary.

What This Guide Offers

We will define the two models, compare their strengths and weaknesses across real carrier scenarios, and provide a decision framework for choosing when to use each—or how to combine them. The goal is not to romanticize the old way nor to blindly champion the new, but to give you a practical lens for designing provenance systems that actually reduce toil and improve reliability.

Foundations Readers Confuse About Provenance and Topology

Two concepts are frequently conflated in carrier network discussions: traceability and observability. Traceability is the ability to follow the path of a specific change or event through the system—who approved it, what tests were run, when it was deployed, and what alerts followed. Observability is the ability to infer the internal state of the system from its external outputs. A digital workflow topology can provide both, but many teams treat them as interchangeable, which leads to gaps.

Another common confusion is between process topology and network topology. The network topology is the physical and logical arrangement of routers, switches, and fiber. The process topology is the sequence of steps that a change or incident follows—ticketing, approval, testing, deployment, verification. When teams design a provenance system, they sometimes mirror the network topology too closely, creating a workflow graph that is as complex as the network itself. That complexity becomes a maintenance burden.

We also see confusion between provenance and metadata. Provenance is not just tagging every configuration file with a timestamp and an owner. Real provenance captures the rationale—the trade-offs considered, the constraints that led to a particular design, the assumptions that were made about traffic patterns. A digital topology that only records what happened, without why, is little better than a syslog dump.

Finally, many engineers confuse the map with the territory. A workflow topology is a model of the process, not the process itself. When the model becomes too abstract—when it omits exceptions, manual workarounds, and human judgment—it loses its ability to guide troubleshooting. The hogan model, by contrast, embraces these irregularities as essential context.

Common Misconceptions

• More granularity always helps. In practice, overly detailed provenance graphs become noise. Teams stop using them.
• Digital provenance is always more reliable than human memory. Only if the system is kept up to date. Many digital topologies drift from reality within weeks of deployment.
• Oral tradition is inherently fragile. It can be surprisingly resilient if cross-trained across multiple people, but it does not scale beyond a certain team size.

Patterns That Usually Work in Carrier Provenance

After observing dozens of carrier operations teams, we have identified three patterns that consistently reduce MTTR and improve confidence in changes.

Pattern 1: The Hybrid Handoff

When a circuit is provisioned or a major maintenance window is completed, the engineer who performed the work writes a brief narrative note in the ticket system—no more than five sentences—explaining any deviations from the standard procedure and any observations about equipment condition. This note is then linked to the automated change record. The digital topology captures the structured data; the narrative captures the context. Teams that do this consistently report fewer repeat tickets for the same issue.

Pattern 2: The Provenance Layer as a Separate Graph

Instead of embedding provenance metadata directly into the network management system, some teams build a separate knowledge graph that links incidents, changes, and design documents. This graph is maintained by the operations team and updated during post-incident reviews. It acts as a long-term memory layer that survives platform migrations. The graph's topology is loose—it does not enforce a rigid workflow—but it is queryable. This pattern works well for teams that have high turnover or that manage diverse network equipment from multiple vendors.

Pattern 3: Periodic Provenance Audits

Once a quarter, a designated team member walks through a sample of recent changes and compares the recorded provenance (both digital and narrative) against the actual state of the network. Discrepancies are logged and used to improve both the workflow topology and the training materials. This practice catches drift early and reinforces the habit of recording context.

When These Patterns Succeed

These patterns work best in carrier environments where the network topology is relatively stable—metro transport rings, long-haul DWDM systems, and IP/MPLS backbones with infrequent greenfield builds. They are less effective in rapidly changing environments like data center interconnect networks or cloud peering points, where the topology shifts weekly and the overhead of maintaining a separate knowledge graph becomes prohibitive.

Anti-Patterns and Why Teams Revert to Older Methods

We have also seen patterns that look good on paper but fail in practice, causing teams to abandon digital workflow topologies and return to manual methods.

Anti-Pattern 1: The Over-Engineered Workflow Engine

Some organizations deploy a full workflow automation suite that requires every action to be logged through a formal approval chain. The intent is to capture complete provenance. But in a carrier environment, where urgent repairs often require skipping steps (e.g., bypassing change advisory board approval for a critical fiber cut), the rigid system becomes a hindrance. Engineers work around it: they perform the repair first, then back-fill the ticket days later, or they keep a separate log. The official provenance becomes incomplete, and the team loses trust in the system.

Anti-Pattern 2: Treating Provenance as a Database Schema

When provenance is designed by a data architect who has never worked on-call, the result is often a normalized schema with foreign keys and strict referential integrity. In theory, this is elegant. In practice, carrier incidents are messy: a single fiber cut may affect dozens of circuits, involve multiple vendors, and span several maintenance windows. Forcing that complexity into a rigid relational model causes data entry errors and omissions. Teams revert to free-text notes or spreadsheets because they are faster and more forgiving.

Anti-Pattern 3: The Dashboard That Replaces the Conversation

A common mistake is to assume that if the digital topology shows all the relevant data, the team no longer needs to talk. We have seen NOCs where engineers sit in silence, staring at screens, because the workflow system "should" tell them everything. But digital provenance rarely captures tacit knowledge—the fact that a particular router has a flaky power supply that only acts up when the temperature exceeds 40°C, or that a certain customer's circuit is historically sensitive to latency spikes. When the dashboard fails to explain an anomaly, the team has no context to fall back on. They then start keeping unofficial notes, which undermines the whole system.

Why Teams Revert

The common thread is that when the digital topology imposes more cost than value, teams revert to the hogan model—informal, relationship-based provenance that is fast and context-rich. The challenge is to design digital systems that are flexible enough to accommodate the messiness of real operations, while still providing the structure needed for audits and automation.

Maintenance, Drift, and Long-Term Costs of Each Approach

Both the hogan model and the highway model have ongoing costs that teams often underestimate at the outset.

Costs of the Hogan Model (Traditional Provenance)

Maintaining institutional memory through people requires deliberate cross-training, documentation of undocumented knowledge, and redundancy. If a key engineer leaves, the cost of rebuilding their mental model can be enormous—weeks or months of lost productivity. Additionally, oral provenance is difficult to audit. Compliance requirements in regulated industries (e.g., telecommunications with regulatory oversight) may demand written records that the hogan model cannot provide.

Costs of the Highway Model (Digital Workflow Topology)

The digital model requires ongoing maintenance of the workflow graph itself. Every time a process changes—a new approval gate, a different testing tool, a revised escalation path—the topology must be updated. If it is not, the graph drifts from reality. We have seen teams that spend more time updating the workflow system than actually fixing network issues. There is also the cost of tooling: licensing, integration, and training. And there is the hidden cost of data rot—provenance data stored in a format that becomes unreadable after a platform migration or a vendor acquisition.

Drift Patterns

Drift happens in both models. In the hogan model, drift occurs when engineers retire or transfer without passing on their knowledge. In the highway model, drift occurs when processes change but the workflow topology is not updated. The highway model's drift is often invisible until an audit or an outage reveals that the recorded process no longer matches the actual one. The hogan model's drift is visible only when someone asks a question that no one can answer.

Long-Term Cost Comparison

For teams with low turnover and stable networks, the hogan model can be surprisingly cost-effective. For teams with high turnover or regulatory requirements, the highway model is usually necessary, but only if the organization invests in keeping the topology current. The most cost-effective approach we have seen is a hybrid: use digital topology for structured data (changes, approvals, test results) and periodic narrative handoffs for context. This combination limits drift in both directions.

When Not to Use a Formal Digital Workflow Topology

There are situations where implementing a formal digital provenance system is not the right choice, at least not as the primary method.

Scenario 1: Very Small Teams (Fewer Than 5 Engineers)

In a small team where everyone knows everyone's work, the overhead of maintaining a digital workflow topology often outweighs the benefits. The hogan model—regular stand-ups, shared notes, and direct conversation—works well. The cost of tooling and maintenance can instead be invested in cross-training and documentation of critical procedures.

Scenario 2: Rapidly Changing Experimental Networks

In research or testbed networks where the topology changes daily and procedures are ad hoc, formal provenance systems become obsolete faster than they can be updated. Engineers will ignore them. It is better to rely on lightweight logging (e.g., a shared journal) and focus on capturing lessons learned after the fact, rather than trying to enforce a workflow topology in real time.

Scenario 3: When the Culture Resists Automation

If the operations team is skeptical of automated workflows and has a history of working around them, force-fitting a digital topology will likely fail. In such cases, it is more productive to start with a minimal system—perhaps just an automated change log—and build trust gradually. Trying to impose a full workflow graph from the start can lead to active sabotage or passive non-compliance.

Scenario 4: When Compliance Requirements Are Minimal

If the network does not need to meet strict regulatory audit standards (e.g., internal corporate networks or pre-production labs), the cost of a formal provenance system may not be justified. The hogan model, supplemented by basic documentation, can suffice.

Decision Checklist

• Is the team size greater than 5? (If no, consider lightweight approach.)
• Is the network topology relatively stable? (If no, delay formal topology.)
• Does the team have a positive attitude toward automation? (If no, start small.)
• Are there regulatory requirements for audit trails? (If yes, digital topology is likely necessary.)
• Is the budget available for ongoing maintenance of the workflow system? (If no, the highway model will fail.)

Open Questions and FAQ

Even after years of working with both models, several questions remain unresolved in the carrier community.

How do we measure the value of provenance?

Most teams track MTTR, but provenance's value also shows up in reduced repeat incidents, faster onboarding of new hires, and fewer audit findings. We suggest tracking a composite metric: average time to find the root cause for the top five recurring incident types. If that time decreases after implementing a provenance system, the investment is paying off.

Can we automate the capture of narrative context?

Some teams are experimenting with AI-assisted log summarization that generates narrative notes from structured data. While promising, these tools still miss the subtleties that a human engineer captures. For now, the best approach is to make it easy for engineers to add free-text notes at key points in the workflow.

Is there a standard topology for carrier workflow provenance?

No single standard exists, but many teams adopt a graph-based model with nodes representing events (changes, incidents, tests) and edges representing dependencies or sequences. The TM Forum's Frameworx and ITIL provide process guidance, but they are not topology specifications. We recommend designing a simple graph that can be extended later, rather than adopting a complex standard that may not fit your operations.

What should we do if our digital topology has already drifted?

First, acknowledge the drift publicly. Then, run a one-time audit to reconcile the recorded workflow with actual practice. Update the topology to match reality, and simplify it if possible. Finally, implement a periodic review cadence (quarterly) to prevent future drift.

Does the hogan model scale beyond a dozen people?

Not reliably. Once a team grows beyond about 12 engineers, the informal knowledge network becomes too sparse. At that point, some form of digital provenance is necessary, even if it is just a shared document with structured fields. The hybrid model becomes essential.

We hope this comparison helps you design a provenance approach that respects both the wisdom of the hogan and the efficiency of the highway. Start by assessing your team size, network stability, and compliance needs. Then choose one pattern from the "Patterns That Usually Work" section and try it for three months. Measure the impact on MTTR and team satisfaction before expanding. The goal is not to build the perfect system, but to build one that your team will actually use.