A business signal is an observable event. An opportunity is a relationship hypothesis with enough evidence, relevance, ownership, and timing to justify a next action. Treating the first as the second creates noisy pipelines and confident but unactionable reports.

The useful transformation is not “collect more news.” It is a controlled workflow that preserves what happened, explains why it may matter to Company A, records what remains unknown, and assigns one bounded validation step.

The transformation contract

Each signal should pass through six questions:

  1. What happened? Record the event without interpretation.
  2. Which entities are involved? Resolve the exact company, subsidiary, facility, product, region, and role.
  3. Why might it matter? State one relationship hypothesis for Company A and Company B.
  4. What supports or contradicts it? Attach dated evidence and counter-evidence.
  5. Who can validate it? Identify an owner or role, not merely an organization.
  6. What happens next and by when? Define a small action and an expiry point.

If a record cannot answer these questions, it remains a signal. It should not silently enter an opportunity pipeline.

Step 1: Normalize the event

Create an event record before writing conclusions. At minimum, store:

  • source URL and publisher;
  • source publication date and observation time;
  • event type and event date;
  • named entities and their roles;
  • geography and business scope;
  • a short evidence excerpt or faithful summary;
  • whether the source is first-party, regulatory, procurement, media, or secondary commentary.

Normalization matters because the same event may appear under a parent company, local subsidiary, brand, or project vehicle. It may also be republished many times. Entity ambiguity and source duplication can create a false sense of corroboration.

Step 2: Form one relationship hypothesis

A hypothesis should connect the event to a specific relationship type. Examples include potential purchasing demand, supply-chain entry, partner complementarity, peer substitution, policy exposure, or a risk to an existing account.

Use a sentence with explicit placeholders:

Because event E changed condition C at Company B, Company A's capability X may be relevant to problem Y within time window T.

This structure makes weak reasoning visible. If the sentence needs vague terms such as “synergy,” “digitalization,” or “strategic fit” without naming a mechanism, the signal is not ready.

Step 3: Build the evidence packet

The evidence packet should contain both support and friction:

  • direct facts that establish the event;
  • facts that establish Company A's relevant capability;
  • facts that connect the capability to the target condition;
  • evidence about timing, stage, or decision window;
  • known incumbents, constraints, prior decisions, or contrary signals;
  • unresolved questions that cannot be answered from public material.

Keep facts and inference in separate fields. The packet should let a reviewer remove the interpretation and still see exactly what the sources establish.

Step 4: Map the decision roles

The company is not the buyer. A real opportunity usually involves several roles:

  • the user who experiences the operational problem;
  • the technical evaluator who tests feasibility;
  • the economic owner who controls resources;
  • procurement or compliance roles that control entry;
  • an internal sponsor who can carry the problem across teams.

At the signal stage, these roles may be unknown. That is acceptable. The workflow should record role hypotheses and confidence instead of inventing a named contact. The next action may simply be to discover who owns the relevant process.

Step 5: Apply timing and decay

Signals lose value at different rates. A tender deadline may decay in days. A facility investment may create a multi-quarter window. A policy change may have a known effective date but uncertain implementation timing.

Every candidate should therefore have:

  • an observed date;
  • a latest useful action date;
  • a review date;
  • a reason for the chosen window;
  • a state to enter when the window closes.

Expiry should not delete the research. It should move the record from “active” to “expired” or “observe,” preserving the evidence for future comparison without presenting it as current.

Step 6: Assign the smallest useful action

The first action should reduce the most important uncertainty, not maximize activity. Examples include:

  • confirm whether the announced project has entered vendor selection;
  • identify whether the relevant system is owned by operations, engineering, or IT;
  • compare Company A's capability boundary with one disclosed requirement;
  • ask a trusted domain contact whether the inferred problem is credible;
  • monitor a specific procurement page until a stated date.

Each action needs an owner, due date, expected evidence, and stop condition. Without ownership, the “opportunity” is only a note.

Use states that reflect evidence maturity

A lightweight state model is enough:

  • Observed: event captured; entity and source normalized.
  • Hypothesized: relationship mechanism stated; initial fit exists.
  • Researching: decisive evidence or role ownership is missing.
  • Qualified: no hard veto; evidence supports a time-bounded next action.
  • Engaging: legitimate contact or direct validation is underway.
  • Closed: validated, rejected, expired, duplicated, or out of scope with a reason.

State transitions should require evidence, not optimism. “Qualified” is not a synonym for “interesting,” and “closed” is not data loss when the outcome is preserved.

A compact example

Signal: Company B announces a regional capacity expansion.

Weak output: “Company B may need automation suppliers. Contact soon.”

Reviewable output:

  • event: first-party capacity announcement, dated and scoped to one facility;
  • hypothesis: the ramp may create a need for process monitoring that overlaps Company A's capability;
  • support: Company A has a relevant deployment pattern; the facility uses a compatible process;
  • unknowns: project stage, incumbent architecture, buying owner, budget, and integration boundary;
  • next action: determine whether monitoring design is open before the engineering freeze date;
  • expiry: reclassify to observe if stage ownership cannot be confirmed by the review date.

The second output is less exciting, but it can be reviewed, assigned, and disproved.

Measure the workflow, not the volume

Useful operating metrics include:

  • share of signals with resolved entities and original sources;
  • share of hypotheses with at least one counter-evidence field;
  • time from observation to first decision;
  • share of qualified records with an owner and due date;
  • expiry rate and reason distribution;
  • proportion of direct validation that confirms, changes, or rejects the original hypothesis.

Counting collected articles or generated leads rewards volume. Measuring decision latency, evidence completeness, and learning quality rewards a system that helps people act responsibly.

The goal is not to turn every signal into an opportunity. It is to reject weak transformations early, preserve strong ones with their evidence, and make the next check obvious.