--- title: "From market signals to operator-ready opportunities" slug: from-signals-to-opportunities kind: Signal pipeline spec source: https://www.joinlegion.io/resources/from-signals-to-opportunities published: 2026-09-03 --- # From market signals to operator-ready opportunities Run one signal through the six stages. A stage that cannot show its evidence stops the record there. Build a small signal system that keeps the event, its evidence, and the decision trail intact until a human approves the next action. The steps below are the ones in the guide at https://www.joinlegion.io/resources/from-signals-to-opportunities. Read it for the reasoning; run this for the work. Nothing here is new: if the guide does not say it, this file does not either. ## Key answer The useful unit is an operator-ready opportunity record: a normalized event, the evidence that supports it, a qualification decision, and a proposed action awaiting approval. That record makes the system inspectable when sources change, a provider fails, or an operator asks why a company reached the queue. ## Alerts are not opportunities An alert says that something happened: a company posted a role, published a launch, or changed a public page. It may be incomplete, stale, duplicated, or irrelevant to the motion you are running. Treating every alert as a prospect moves noise downstream. An opportunity is narrower. It has passed a defined relevance test and retains the source URL, observed time, and reason it passed or failed. It can still be rejected by an operator. The distinction protects the queue from becoming a disguised inbox. ## The six-stage signal pipeline - [ ] 1. Normalize and validate Turn a provider-shaped event into one stable contract. - [ ] 2. Deduplicate Collapse repeated observations before research. - [ ] 3. Research and preserve evidence Keep sources apart from the conclusion. - [ ] 4. Qualification gate Apply the written relevance rules. - [ ] 5. Operator queue Present display-safe records for review. - [ ] 6. Approved destination Release only the action an operator permits. Six stages run left to right, and every stage can stop the record. Normalize and validate turns a provider-shaped event into one stable contract; a record that fails validation never moves on. Deduplicate collapses repeated observations of the same event before any research is paid for. Research and preserve evidence keeps the source separate from the conclusion, so a later reader can check both. The qualification gate applies the written relevance rules and drops anything that does not match them. The operator queue presents display-safe records for a person to review. The approved destination releases only the action an operator permits, so the pipeline ends at a human decision rather than at an automation. Normalization is the contract between a changing source and the rest of the system. A useful event includes a type, company or entity, observed timestamp, source URL, and a short factual summary. Reject malformed events early. That lets later stages work with one known shape rather than a growing collection of provider exceptions. Deduplication belongs before research because duplicate alerts can create duplicate work and competing conclusions. Research then adds evidence, not just a score. Preserve what was found, where it was found, and when it was observed. A conclusion without its trail is difficult to re-check. ## What belongs inside each boundary Keep the intake, research, and control plane responsibilities separate. Intake accepts and validates events. The research boundary collects evidence and produces a record. The control plane shows the queue and exposes authenticated actions. This is less about a particular vendor than about making responsibility visible. Narrow provider adapters help preserve these boundaries. A scheduler, enrichment source, model, database, or destination can change without rewriting the meaning of the opportunity record. They also make it easier to test a source failure without faking a full workflow. ## Qualification is a control point Qualification should be an explicit gate, not an opaque score that silently sends work onward. Write down the signal family, minimum evidence, disqualifiers, and the only actions the workflow may propose. Record both acceptance and rejection reasons. A rejected record can be more useful than a silent drop when you refine a rule later. A practical first gate asks: is the event valid, is the entity in scope, is the evidence current enough for this use, and is the next action permitted? If any answer is unclear, leave the record in review or reject it. The goal is a smaller queue whose status is legible, not maximal throughput. ## Operate the system safely Run one source and one destination before adding coverage. For each scheduled run, record received events, validation rejections, duplicates removed, completed research, accepted and rejected opportunities, retryable failures, and actions awaiting approval. These checks expose where the handoff is breaking without claiming that a provider will behave consistently. Use a server-side workflow switch for every signal family. A paused workflow should stop before paid or irreversible work. Missing configuration should fail closed. Review provider quality, data rights, and pricing against current documentation rather than copying assumptions from another operator. ## Keep the security boundary visible Visible limitation: The public kit is a reference implementation, not a copy of a production environment. It intentionally excludes production credentials, customer configurations, private domains, internal account identifiers, campaign copy, proprietary datasets, and live infrastructure details. Never place provider tokens, database service keys, private webhook URLs, or authorization decisions in browser code. Keep secrets in a deployment platform's secret store; authenticate control-plane mutations on the server; allow-list fields before storage; and scan the final archive after compression. Signed download links and webhook callbacks are a separate concern from the public records a browser may display. ## What the public kit includes The Signal System Kit provides generic architecture, source skeletons, prompt templates, example payloads, deployment guidance, and operating procedures. Its three documented system areas are signal intake, a research router, and a control plane for an operator queue. The package also includes an example operator configuration, a sample signal event, provider guidance, a secrets-name manifest, and rebuild prompts. It does not prescribe private accounts, endpoints, commercial terms, or a single production setup. Validate integrations and their current documentation before deploying a derivative. ## Start with one signal Choose one signal that has a clear source and one downstream decision you are willing to review. Define the normalized event fields, one deduplication rule, the evidence required to qualify it, and the action that still needs approval. Run it end to end with example data first. Add a second signal only after you can explain why the first record reached the queue and how you would stop it. ## Where the working files are The full protocol, role contracts and setup files for this system live in the Legion community: https://www.skool.com/legion/about