The Signal Taxonomy: A Classification Framework for Program Intelligence

Published on Sep 4, 2026

The Signal Taxonomy

A Classification Framework for Program Intelligence

Complex programs do not have an information shortage. They have a classification problem.

A large enterprise program can produce an astonishing amount of information while remaining impressively unclear about what is actually happening.

Meeting notes pile up. Dashboards glow. RAIDD logs age gracefully in shared folders. Work items move. Pull requests merge. Teams channels hum. Slack threads wander into the wilderness. Steering committees review carefully color-coded versions of reality.

Then someone asks a normal question:

What changed this week that leadership should care about?

The room goes quiet.

Not because the answer does not exist.

The answer exists in twelve places, using seventeen different phrases, owned by six people who do not realize they are describing the same problem.

One team says it is “waiting on an upstream dependency.” Another says the item is “pending confirmation.” A third says the risk is “being monitored.” Someone in a Teams thread says, “This probably will not make the window.” The official status remains green because apparently a risk is not a risk until it shows up in the correct RAIDD log.

That is not an information problem.

It is a classification problem.

Before a program can detect weak signals, correlate patterns, automate escalation, or ask AI to explain what matters, the enterprise has to define what counts as a signal in the first place.

Before AI can find the signal, the enterprise has to decide what counts as one.

That is the job of a signal taxonomy.

The Short Version

If you only remember six things from this article, make them these:

• Program truth is distributed across conversations, work systems, decisions, risks, evidence, and human memory.
• A shared taxonomy gives different teams a common vocabulary for recognizing and classifying signals.
• Traditional RAIDD categories remain useful, but they do not capture the full weak-signal landscape of modern enterprise delivery.
• Signals need attributes such as source, owner, age, recurrence, confidence, velocity, affected outcome, and evidence.
• Deterministic rules, analytics, generative AI, and agentic investigation all become more useful when they operate on a stable semantic layer.
• A signal taxonomy is the nervous system underneath program intelligence, including our upcoming lightweight delivery acceleration methodology, BRIDGE.

Everyone Is Talking About Context. Almost Nobody Is Talking About Meaning.

More context does not automatically create more intelligence. Sometimes it creates a larger pile of ambiguity with a better search function.

Context engineering is becoming one of the loudest conversations in enterprise AI.

That makes sense. An AI system behaves differently depending on what data it can access, which tools it can use, what instructions it receives, what memory it retains, and what information gets retrieved at the moment of decision. Salesforce describes context engineering as designing the broader information environment around an agent: data sources, knowledge, tools, instructions, and memory. source source

Good.

The enterprise should absolutely care about context.

But context without semantics simply allows the enterprise to misunderstand more information, faster, while trying to force an Agentic value case.

Everyone is talking about giving AI more context. Almost nobody is asking whether the enterprise has a stable vocabulary for the signals inside that context.

If one team calls something a blocker, another calls it a dependency, a third calls it pending, and a fourth records it as a discussion item, the system still has work to do before those fragments become intelligence.

The model may understand the words.

The enterprise still needs to agree on the operational meaning.

That distinction matters because program intelligence is not merely text classification. It is the disciplined translation of messy enterprise language into decision-useful objects.

Without a stable vocabulary, AI can summarize the confusion beautifully.

We already have people for that.

A Taxonomy Turns Language Into Operational Meaning

Taxonomies are not glamorous.

Nobody has ever kicked off a keynote by yelling, “Get ready for the controlled vocabulary.”

Still, shared classification keeps six teams from describing the same problem six different ways and wondering why no one took action.

The MIT AI Risk Repository consolidates more than 1,700 AI risks from dozens of frameworks and organizes them through causal and domain taxonomies. The purpose is practical: inconsistent terminology makes risks harder to compare, prioritize, govern, and address. source

OpenTelemetry uses semantic conventions for a similar reason. Common names for operations and data allow traces, metrics, logs, and resources to be understood consistently across codebases, libraries, and platforms. Its generative AI conventions now include standardized attributes for agents, conversations, data sources, evaluations, and other execution details. source source

Program delivery needs the same discipline.

A signal taxonomy gives teams and systems a shared frame of reference for questions such as:

• What type of signal is this?
• What outcome could it affect?
• Is it new, recurring, accelerating, or stale?
• Is it a fact, an inference, a concern, or a decision?
• Does it require action, investigation, monitoring, or escalation?
• What evidence supports it?
• Who owns the next move?

Without that shared frame of reference, program intelligence becomes a collection of opinions with timestamps.

With it, the enterprise can compare, correlate, route, measure, and learn.

In other words, the enterprise can actually do something about the issues that come up, and get better over time.

Start With RAIDD. Then Admit Your Program Is Bigger Than the Log.

RAIDD gives the program a useful core vocabulary. Modern delivery intelligence needs a wider field of view.

Most program leaders already recognize the familiar categories:

• Risks: uncertain events or conditions that may affect outcomes.
• Actions: work someone has committed to completing.
• Issues: conditions already affecting delivery.
• Dependencies: work, decisions, capabilities, or conditions required from somewhere else.
• Decisions: choices that establish direction, constraint, ownership, or tradeoffs.
• Deferrals: work or decisions intentionally postponed, usually with future consequences attached whether anyone admits it or not.

That is a strong foundation.

It is not enough. Not even close in a modern, complex delivery program.

Modern programs generate a much wider field of weak and emerging signals. These signals often appear before a formal risk or issue exists. By the time the signal graduates into the official log, the program may already be paying dearly for it.

A broader taxonomy should include at least these classes.

Blockers

Something is actively preventing progress.

A blocker is not the same as a dependency. A team can have a dependency that is healthy and scheduled. A blocker has already stopped or materially constrained movement.

Assumptions

A belief the plan depends on.

Assumptions deserve attention because enterprise plans frequently treat them like facts until reality sends a correction with late fees.

Ownership gaps

A condition, decision, action, or risk lacks a clearly accountable owner.

“Shared ownership” is sometimes collaboration. Sometimes it is an elegant way to make sure nobody gets blamed before the steering committee.

Evidence gaps

A claim, readiness position, control, or decision lacks sufficient proof.

The work may be complete. The organization may simply be unable to demonstrate it. In regulated delivery, that distinction can blow up everybody’s weekend.

Readiness gaps

A release, operating capability, support model, control, environment, or stakeholder group is not prepared for the next transition.

Readiness gaps matter because code completion and enterprise readiness are distant relatives who exchange holiday cards but rarely live together.

Control gaps

The required guardrail, approval, validation, monitoring mechanism, or exception path is missing or ineffective.

Intent drift

The work has moved away from the outcome, constraint, or purpose that originally justified it.

Intent drift is especially dangerous because teams can remain productive while becoming progressively less relevant to business value.

Repeated uncertainty

The same unresolved concern keeps resurfacing across meetings, channels, or status cycles.

A single “we should confirm” may be ordinary delivery chatter. The fifth instance of it just might be the program waving both arms and screaming bloody murder.

Reopened decisions

A decision believed to be settled returns because evidence, ownership, stakeholder alignment, or downstream consequences were never strong enough to keep it closed.

Dependency churn

Dependencies are repeatedly added, removed, reworded, reassigned, or rescheduled.

Churn often signals weak architecture, unstable scope, unclear ownership, or a plan being repaired while leadership admires the baseline.

Commitment decay

A commitment remains nominally open while dates move, language softens, urgency fades, and confidence quietly begins looking for the exit.

Escalation avoidance

People recognize a concern but repeatedly frame it below the threshold required for action.

This may look like diplomacy. Sometimes it is fear walking around wearing business casual.

Signals Need More Than a Label

Calling something a dependency is useful.

It is also the beginning of the work.

A signal becomes operationally valuable when it carries enough structure to support a decision.

A label tells the enterprise what kind of signal it found. Attributes explain whether anyone should care right now.

A mature signal object should include attributes such as:

• Source: Where did the signal originate?
• Timestamp: When did it first appear and when was it last observed?
• Signal class: Risk, dependency, decision, evidence gap, intent drift, or another defined type.
• Affected outcome: Which intent, milestone, customer outcome, release, control, or value target could be affected?
• Owner: Who is accountable for validation or response?
• Confidence: How certain are we that the signal means what we think it means?
• Severity: What is the potential consequence?
• Age: How long has it remained unresolved?
• Recurrence: How often has it appeared?
• Velocity: Is the condition stable, improving, or accelerating?
• Scope: Is it local to one team or spreading across the program?
• Evidence: What artifacts, messages, events, or data support it?
• Related signals: What else may be connected?
• Lifecycle state: Candidate, validated, active, mitigated, closed, accepted, or rejected.
• Required response: Monitor, investigate, act, escalate, decide, or accept.

These attributes help distinguish a casual comment from a material delivery condition.

Consider these two statements:

“We are waiting for the API team.”

“Three workstreams have referenced the same API dependency in four forums over nine days. No owner is recorded. The release window is twelve days away.”

The first is information.

The second is intelligence.

It’s the same basic concern, but a more useful structure, no?

And, it allows you to have a very different conversation.

Signal Strength Comes From Patterns

Programs often wait for a signal to become loud.

That is convenient because loud signals are easy to recognize. They are also usually late.

Weak-signal intelligence depends on patterns:

• recurrence across sources
• worsening language
• increasing age
• ownership instability
• repeated deferral
• decision reopening
• growing blast radius
• clustering around one platform, vendor, environment, or capability
• divergence between official status and delivery evidence
• inconsistency between stated intent and actual work

A single message saying “test data may be late” may deserve monitoring.

The same concern appearing in test planning, a Teams channel, two work items, and a release-readiness discussion deserves something stronger than another meeting invitation.

This is where the taxonomy becomes the semantic layer for program intelligence.

Deterministic rules can flag missing owners, overdue actions, repeated mentions, unsupported readiness claims, and stale decisions.

Analytics can measure recurrence, aging, concentration, velocity, and correlation.

Generative AI can summarize the pattern, translate technical language, and explain why the signal matters.

Agentic investigation may trace related evidence across systems, compare competing explanations, or recommend the next best question.

Humans still decide what the enterprise should do.

That last sentence remains stubbornly important.

PMI’s 2026 AI standard for project work makes a similar distinction: AI can process information, identify patterns, surface risks, and generate recommendations, while people remain accountable for interpretation, organizational context, stakeholder dynamics, and consequences. source source

The taxonomy makes each layer more useful because each layer is operating on shared meaning.

The Signal Pipeline Should Use the Full Automation Continuum

The machine should do the repetitive extraction. Analytics should find the pattern. AI should explain the ambiguity. Humans should own the consequence.

A signal taxonomy does not require every signal to pass through an agent.

Thank goodness. We have enough expensive hobbies.

The signal pipeline should use the cheapest, safest, most controllable mechanism that can reliably handle each step.

Ingest deterministically

Collect approved artifacts from work systems, repositories, risk logs, meeting notes, collaboration channels, test systems, change records, and delivery platforms.

Preserve source references and timestamps.

Normalize with rules

Map known fields and phrases into candidate signal classes.

Flag obvious conditions:

• missing owner
• overdue action
• unresolved dependency
• repeated deferral
• stale decision
• absent evidence
• readiness claim without support

Measure with analytics

Track age, recurrence, concentration, velocity, relationships, and divergence.

Synthesize with generative AI

Explain signal clusters in language appropriate for delivery teams, executives, risk partners, or governance forums.

Investigate with agents where earned

Use agentic reasoning for ambiguous, multi-source questions:

• Why does this dependency keep resurfacing?
• Which decisions appear connected?
• What outcome is threatened?
• What evidence is missing?
• Which signal should leadership address first?

Decide with humans

Validate the signal. Accept the risk. Change the plan. Escalate the issue. Approve the exception. Own the outcome.

The taxonomy supports all of those mechanisms without pretending they are interchangeable.

This is AI-pragmatic program intelligence, and I have a feeling it will start growing in popularity very soon.

Financial Services Needs Traceable Signals

Financial Services programs have no shortage of reasons to care about signal quality.

A weak signal can become:

• release failure
• customer impact
• control breakdown
• regulatory exposure
• fraud vulnerability
• operational resilience concern
• financial loss
• audit issue
• third-party failure
• evidence deficiency

The enterprise cannot responsibly route those concerns based on a model saying, “This feels risky.”

Each material signal needs lineage:

• original source
• extracted text or event
• classification method
• rules applied
• analytics calculated
• AI-generated interpretation, if any
• confidence and limitations
• human validation
• action taken
• final disposition

NIST’s AI Risk Management Framework organizes dependable risk management around the continuous functions of Govern, Map, Measure, and Manage, with governance operating across the lifecycle. The framework emphasizes transparent roles, risk-based controls, monitoring, accountability, and documented practices. source source

That same discipline belongs in program intelligence.

If the signal changes funding, readiness, release, control posture, or executive action, leaders should know where it came from and how it was interpreted.

“The AI found it” is not lineage, nor is it acceptable.

The Taxonomy Is Also a Cultural Choice

Signal systems can become useful intelligence infrastructure.

They can also become surveillance with pretty pictures.

That distinction depends on design and leadership.

A responsible taxonomy focuses on delivery conditions, not employee personality.

It should classify:

• unresolved dependency signals
• evidence gaps
• decision delays
• ownership ambiguity
• intent drift
• repeated blockers
• readiness concerns

It should not classify:

• who sounds negative
• who appears insufficiently enthusiastic
• who asks inconvenient questions
• who should be performance-managed because an algorithm disliked a sentence fragment

The purpose is to help the program see itself.

The purpose is not to make employees wonder whether every Teams message is testifying against them.

This matters even more as collaboration signal ingestion expands into approved Teams and Slack channels. The delivery truth often appears there before the status deck catches up. Governance must establish approved spaces, purpose limitations, source traceability, minimal retention, human review, and clear prohibitions against employee scoring.

If people stop surfacing concerns because the signal system feels punitive, the program did not become more intelligent.

It blinded itself with software.

Where Leaders Get This Wrong

They create too many categories

A taxonomy with 147 signal types may impress the design team and punish everyone else.

Start with a small set that people understand. Expand when recurring evidence proves the need.

They confuse keywords with signals

The word “risk” does not automatically create a risk signal.

The phrase “looks good” does not automatically create confidence.

Language needs context, recurrence, evidence, and relationship to outcomes.

They make every signal urgent

If everything is critical, the taxonomy has become a siren factory.

Signal quality depends on proportionality.

They detach signals from intent

A dependency matters because of what it threatens.

An evidence gap matters because of the claim it fails to support.

A decision delay matters because of the outcome it blocks.

Signals without intent are loose alarms rolling around the enterprise.

They automate escalation before trust exists

Start with candidate signals and human validation.

Earn automation through precision, transparency, and measured performance.

Nobody wants an eager machine escalating something because three engineers used the phrase “not ideal.”

They treat the taxonomy as a one-time workshop artifact

Language changes. Delivery models change. New sources appear. Signal classes overlap. False positives teach the system something.

The taxonomy needs stewardship, versioning, feedback, and retirement rules.

Otherwise it becomes another beautiful framework frozen in amber while the work moves on without it.

What Good Looks Like

A mature signal taxonomy helps the enterprise move from scattered observations to traceable patterns, governed decisions, and earlier action.

A healthy signal-intelligence system feels quieter than the current mess.

Fewer duplicate trackers.

Fewer arguments about whether two teams are describing the same condition.

Fewer risks appearing for the first time in executive forums.

Fewer decisions returning from the dead.

Leaders can see:

• which signals are new
• which signals are recurring
• which signals are accelerating
• which outcomes are threatened
• which signals lack owners
• which claims lack evidence
• which dependencies are clustering
• which decisions are aging
• which readiness positions are weakening
• which signal deserves attention now

The system does not replace leadership judgment.

It gives judgment better material.

That is the point.

A program should not need the one exhausted human who has attended every meeting since kickoff to explain what is really happening.

That person deserves a vacation.

The program deserves a nervous system.

Where This Points Next

The taxonomy is the vocabulary.

The next capabilities build on it.

CLEAR, the Consolidated Launch and Engineering Alignment Relay, helps preserve the original intent and attach that intent to engineering execution, evidence, readiness, and value.

RADAR can use the taxonomy to detect, classify, correlate, and escalate signals emerging across meetings, collaboration channels, repositories, work systems, tests, risks, and decisions.

BRIDGE connects the larger operating model: strategy, intent, execution, governance, evidence, signals, readiness, and value.

That is the rollout.

Not just a product parade.

A sequence of problems and capabilities:

1. Define what counts as a signal.
2. Capture what the work is supposed to accomplish.
3. Listen to what execution is actually saying.
4. Connect the thread from strategy to governed value.

The Signal Taxonomy belongs first because intelligence cannot be consistent until language becomes consistent.

Final Thoughts

Programs are already talking.

They talk through meetings, work items, decisions, pull requests, test failures, channel messages, deferrals, risks, and the sentence someone quietly adds at the end of a status update because putting it first would frighten the room.

The enterprise does not need more raw language.

It needs shared meaning.

A signal taxonomy turns scattered observations into a structured vocabulary that people and systems can use together.

It gives deterministic automation something to flag.

It gives analytics something to measure.

It gives generative AI something to explain.

It gives agents something coherent to investigate.

It gives leaders something better than vibes to govern.

Before AI can find the signal, the enterprise has to decide what counts as one.

Do that well, and program intelligence becomes possible.

Skip it, and the enterprise may spend a great deal of money teaching machines to misunderstand the same program language that humans have been arguing about for years.

That would certainly be very modern.

It would also not be very smart.

Join the Conversation

What signals does your program routinely miss?

Risks that appear too late?

Dependencies hidden inside ordinary conversation?

Decisions that keep reopening?

Evidence gaps discovered during readiness reviews?

A workstream that remains green while every surrounding signal suggests it is being held together by optimism and duct tape?

Which signal classes belong in a practical enterprise taxonomy?

And where should the line be drawn between delivery intelligence and employee surveillance?

I would love to hear your real-world version.

Not the clean PMO answer.

The version from the messy middle, where the language was available all along and nobody had agreed on what it meant.

About the Author

Joe Mack is a Technology Consulting Senior Principal specializing in technology leadership, enterprise SDLC transformation, release management, deployment governance, and delivery optimization for household name Financial Services companies. Joe is also a lifelong self-learner and builder of systems, and Free Tier Life is one of the ways he is trying to turn those experiences and instincts into something other people can actually use.

Bibliography

• Project Management Institute. “The New AI Standard: A Shared Foundation for Responsible Adoption.” July 13, 2026.
• Project Management Institute. “The Standard for Artificial Intelligence in Portfolio, Program and Project Management.” June 2026.
• MIT AI Risk Initiative. “MIT AI Risk Repository.” Accessed September 2026.
• Salesforce. “8 Ways AI Agents Are Evolving in 2026.” August 4, 2026.
• Salesforce. “An Agentforce Guide to Context Engineering.” Accessed September 2026.
• OpenTelemetry. “Semantic Conventions.” Accessed September 2026.
• OpenTelemetry. “Inside the LLM Call: GenAI Observability with OpenTelemetry.” May 14, 2026.
• National Institute of Standards and Technology. “AI Risk Management Framework.” Accessed September 2026.
• NIST AI Resource Center. “AI RMF Core.” Accessed September 2026.