# AlphaBurst Economic Relationship and Idea Rules

Last updated: 2026-09-07

This file defines the non-negotiable classification, evidence, dating and graph-maintenance rules for the Supply Chain / Economic Relationship product. Examples in requirements, prompts or mockups are research leads, not facts.

## 1. Hypothesis versus Idea

### Hypothesis

A card must be tagged **HYPOTHESIS** when any economically material part of its causal chain remains proposed, one-sided, unquantified, stale, unresolved or supported only by contextual evidence. A hypothesis may show a conditional LONG or SHORT direction, but the direction must never be presented as a validated recommendation.

This includes:

- a chain suggested by a user, model or analogy;
- a relationship inferred from only one company's disclosure;
- a named beneficiary whose own management, filings and operating constraints have not been evaluated;
- a chain containing an unsupported material hop;
- an exposure whose revenue, margin, capacity, timing or valuation materiality is not quantified;
- unresolved contradictory evidence; or
- evidence that is no longer current enough for the claimed relationship.

### Idea

A card may be promoted to **IDEA** only after all required gates pass:

1. **Entity resolution:** every named public company and material counterparty is correctly identified.
2. **Dated provenance:** every material assertion links to its source, document type, publication date, relevant reporting period, ingestion time and exact evidence excerpt or location.
3. **Management review:** the target company's latest relevant transcript and filings have been evaluated. Material upstream, downstream, customer, supplier or competitor disclosures are also evaluated when available.
4. **Both sides tested:** the supporting case and the strongest counter-thesis are explicitly researched using evidence, not merely generated as prose.
5. **Causal validation:** each material hop has observed support or a clearly tested economic mechanism. Graph adjacency alone is not causation.
6. **Materiality:** the effect is quantified against company revenue, volume, costs, margins, capacity, earnings or cash flow. A plausible chain with immaterial economics does not become an idea.
7. **Timing:** the expected transmission lag, catalyst and relevant reporting window are supported.
8. **Recency check:** newer disclosures have been compared with older evidence and no unresolved newer evidence invalidates the chain.
9. **Independent challenge:** the disconfirmation review passes for causality, materiality, timing, substitution, supply response and consensus/pricing.
10. **Publication gate:** required review and configured confidence thresholds pass. A model cannot directly self-publish an Idea.

If any required gate later fails, the Idea must be downgraded to Hypothesis, marked stale, revised or withdrawn. Historical classifications remain auditable.

Confidence wording or a high model score cannot substitute for these gates.

## 2. Display rules

- Every surfaced card must display exactly one classification: **HYPOTHESIS** or **IDEA**.
- Conditional direction is displayed separately: for example, `HYPOTHESIS · LONG FEAM`.
- A Hypothesis must identify missing validation and must not use language implying that the relationship is established.
- An Idea must show its as-of date, evidence coverage, causal lineage, materiality, catalyst, timing, principal risk and counter-thesis.
- Contextual evidence must be labeled as context; it cannot be shown as proof of a different company or a later causal hop.
- Demo prices, scores and returns must be visibly labeled and cannot enter validation or ranking.

## 3. Incremental document ingestion

Every newly ingested transcript, filing or approved source document must be evaluated against the current versioned economic graph—not only against the issuer's existing page.

For each new document, the pipeline must:

1. Record immutable source metadata and a content hash: issuer, form/document type, publication timestamp, reporting period, ingestion timestamp, source location and document version.
2. Detect changed sections and embed only new or materially changed chunks when possible. Reuse unchanged embeddings by content hash.
3. Extract dated entity mentions, products, customers, suppliers, competitors, substitutions, commodities, capacity, regulation, geography, lead times, pricing and demand/cost signals.
4. Resolve entities and compare each extracted assertion with relevant existing nodes and edges across supplier, customer, competitor, upstream, downstream, substitute, raw-material, capacity and policy relationships.
5. Create, confirm, weaken, contradict, supersede or close relationship assertions. Never overwrite history silently.
6. Re-run only affected traversals, Hypotheses and Ideas, including upstream and downstream dependants within the configured hop and cost budget.
7. Re-run materiality, timing and counter-thesis checks for affected cards and record classification changes with reasons.
8. Publish a new graph snapshot only after validation; retain the prior snapshot for rollback and audit.

## 4. Dating and recency

Every document, assertion, edge, graph snapshot, Hypothesis and Idea must carry dates sufficient to reconstruct what the system knew at any point in time.

Required graph fields include `observed_at`, `source_published_at`, `source_period_end`, `ingested_at`, `valid_from`, `valid_to`, `last_confirmed_at` and `supersedes` where applicable.

The latest relevant reliable evidence receives priority, because suppliers, customers, products and economic mechanisms can change. Recency is not a license to discard history:

- preserve older assertions and their provenance;
- close or supersede an edge rather than deleting it;
- prefer an amended filing or explicit current management statement over an older statement about the same period;
- compare dates and reporting periods, not ingestion order alone;
- retain conflicts when newer evidence does not conclusively resolve them; and
- mark a relationship stale when it exceeds its configured refresh window or a company reports a material change.

## 5. Evidence and inference boundaries

- A statement from Company A does not establish Company B's exposure without corroboration or a validated economic bridge.
- Shared generic labels such as “steel suppliers” do not prove that two issuers share a supplier.
- A supplier/customer relationship does not by itself establish benefit, harm or earnings materiality.
- Every scenario edge must state its assumption and failure condition.
- Missing evidence remains missing; it is never converted into a zero, a fabricated score or a confident conclusion.
- Exact source evidence and extracted claims must remain traceable through every displayed lineage edge.

## 6. Cost-aware processing

- Interactive economic queries use `gpt-5.6-sol` with high reasoning by default.
- A single interactive query has a hard application budget ceiling of **$0.30**, including its question embedding and the synthesis request. The request must reserve conservatively for input, reasoning and visible output before it is sent.
- If the retrieved context cannot leave a useful answer allowance within $0.30, the query must fail explicitly or reduce retrieval under a separately validated policy; it must never silently exceed the ceiling.
- Hash and deduplicate documents before embedding.
- Embed changed chunks rather than repeatedly embedding complete historical documents.
- Use graph neighborhoods, metadata filters and lexical retrieval to bound semantic search.
- Reuse cached embeddings and prior extraction results when the source content and schema/prompt versions are unchanged.
- Deep model review is reserved for affected relationships, contradictions, materiality and publication gates.
- Cost optimization may reduce repeated processing; it must not skip relevant new disclosures or conceal evidence coverage gaps.

## 7. Audit and operational safety

- Every graph mutation and card-classification transition records its cause, source IDs, model/rule version, timestamp and prior value.
- Processing is idempotent and resumable using content hashes and checkpoints.
- Failed jobs cannot partially publish a graph snapshot or promote an Idea.
- Production deployment, database migrations and scheduled workers require separate review, rollback and single-owner controls.
- These rules apply to local prototypes and production outputs. Prototype status does not permit unsupported claims.

## 8. Extreme momentum-claim governance

This section is a fail-closed publication rule. It overrides looser wording elsewhere in the product.

### 8.1 Distinguish the measurements

- A high level is not growth. Example: high backlog does not prove backlog grew.
- Growth is not acceleration. Acceleration requires the growth rate itself to increase on a comparable basis.
- Contraction is not deceleration. A negative year-over-year rate establishes contraction; deceleration requires a comparable prior growth rate and a lower current rate.
- “Strong,” “robust,” “improving,” “momentum,” “inflection” and similar management adjectives are narrative claims, not measured acceleration.
- Guidance, pipeline, bookings, backlog, revenue, units, price, margins and earnings are different metrics. Momentum in one cannot be relabeled as momentum in another.

### 8.2 Required structured evidence

No heading, card, alert, search answer or lineage may say `accelerating`, `decelerating`, `reaccelerating`, `inflecting`, or an equivalent unless its sensor record contains:

1. the exact metric, unit, entity and business scope;
2. at least two comparable growth rates, or enough dated observations to calculate them;
3. current and prior periods with the same sequential/year-over-year basis;
4. actual-versus-guidance classification;
5. source publication dates and exact evidence locations;
6. the arithmetic used to classify acceleration or deceleration;
7. restatement, acquisition, foreign-exchange, price/volume and accounting-basis checks where material; and
8. a contradiction search in the latest relevant filing/transcript and, for an Idea, material counterparties or an independent primary source.

Three comparable observations are preferred. Two growth-rate observations may trigger a **Hypothesis** but cannot alone promote an **Idea**.

### 8.3 Sensor states and feed eligibility

Every proposed card must store exactly one sensor state:

- `OBSERVED_ACCELERATION` or `OBSERVED_DECELERATION`: comparable actual measurements and arithmetic support the change in growth rate;
- `OBSERVED_GROWTH` or `OBSERVED_CONTRACTION`: direction is measured, but acceleration/deceleration is not established;
- `GUIDANCE_CHANGE`: management changed a forecast; must never be displayed as an actual result;
- `MANAGEMENT_NARRATIVE`: qualitative issuer claim without sufficient comparable measurements;
- `STRUCTURAL_ONLY`: a relationship map or scenario with no current change sensor; or
- `CONTRADICTED` / `STALE`: newer evidence conflicts with or has overtaken the signal.

Only observed states and explicitly labeled guidance changes may enter the live sensor feed. `STRUCTURAL_ONLY` material remains available in research, but must display **NO ACTIVE SIGNAL / NO TRADE** and cannot be ranked as a current opportunity. `MANAGEMENT_NARRATIVE` may create a review task, not a momentum alert.

### 8.4 Lineage and two-way validation

- A validated root sensor authorizes traversal; it does not validate any downstream benefit or loss.
- Each hop separately records relationship evidence, economic direction, date, transmission mechanism, materiality and failure condition.
- Critical public-company edges must be checked from both companies when disclosure is reasonably available. Silence by the counterparty is `not corroborated`, never confirmation.
- Actual reported results outrank narrative language; newer comparable evidence outranks older evidence. Conflicts remain visible and block Idea promotion.
- An upstream improvement can harm a downstream buyer through price, or help it through availability. The engine must test both signs rather than inherit the root sensor's direction.
- If the root sensor is corrected or withdrawn, all dependent traversals and cards are automatically re-evaluated, versioned and, where necessary, removed from the live feed.

### 8.5 Headline lint and zero-tolerance correction

- Headlines are generated from the structured sensor record, not free-form model prose.
- A deterministic pre-publication linter blocks momentum vocabulary when the required sensor state and fields are absent.
- Forecasts use `expects`, `guides` or `projects`; issuer-reported actuals use `reported`; independently calculated facts show the calculation.
- Words implying causality or realized benefit—including `drives`, `benefits`, `winner`, `surge` and `boom`—must be conditional unless validated material earnings transmission is established.
- Discovery of an inflated claim requires immediate correction, dependency re-run and audit entry. It is not silently edited out of history.

## 9. Industry, micro-industry and shared-driver taxonomy

This section is a fail-closed rule against category leakage. A broad industry classification, a product-function micro-industry and an economic driver are three different facts. They must be stored as different node and edge types and must never be substituted for one another.

### 9.1 Three separate classification layers

1. **Broad classification prior:** `TickerUniverse.csv` supplies the initial `Sector` and `Industry` labels for public-company coverage. It is a screening and navigation reference, not proof of products, competitors, suppliers, customers or causal exposure. Its source name, snapshot date and row identity must be retained.
2. **Micro-industry / product-function membership:** a company or segment may belong to one or more narrowly defined functional groups based on what it actually makes, sells or performs. Examples include conduit/raceway/cable management, wiring/connectors, grounding/boxes, utility equipment, switchgear, transformers and electrical installation. Membership requires product-level primary-source evidence and may be partial, segment-specific or time-bounded.
3. **Economic driver / force exposure:** demand, cost, policy, technology or capacity forces—such as data-center buildout, grid capital expenditure, copper prices or a regulation—are separate nodes. A driver may connect companies in different micro-industries without making those companies direct competitors, suppliers, customers or members of the same micro-industry.

### 9.2 Evidence required for micro-industry membership

- Do not assign a micro-industry from a company name, a ticker match, a broad Finviz industry, a single generic keyword or unconstrained model inference.
- Use the latest relevant 10-K/20-F business description and product disclosures as the baseline. Use 10-Q, 8-K, transcripts and issuer product pages to confirm changes, applications and current segment scope.
- Store the precise products, services, manufacturing functions or applications supporting membership, with evidence IDs, excerpts, dates and issuer/segment scope.
- A company may have multiple micro-industry memberships. Each membership must record `proposed`, `accepted`, `corrected`, `rejected`, `stale` or `superseded` status independently.
- When only part of a company belongs to a micro-industry, attach membership to the segment, product family or subsidiary when possible; do not label the entire issuer without qualification.
- Revenue share, product importance and geography are separate attributes. If they are unknown, store `unknown`; do not infer materiality from membership.
- Conflicting or ambiguous classifications enter an analyst review queue. Newer product discontinuations, acquisitions, divestitures and segment reorganizations supersede rather than erase prior membership.

Minimum micro-industry membership fields are: stable taxonomy ID, display label, parent broad industry, company/segment/product scope, membership status, evidence IDs, `valid_from`, `valid_to`, `last_confirmed_at`, extraction/rule version and reviewer decision.

### 9.3 Relationship-type firewall

- Companies sharing a broad industry or micro-industry have a `CO_MEMBER_OF` classification relationship only. Co-membership does not prove competition.
- Companies sharing an economic driver have an `EXPOSED_TO_DRIVER` relationship only. Shared exposure does not prove that their revenue, margins or stocks move together.
- `SUPPLIES`, `CUSTOMER_OF`, `DISTRIBUTES`, `COMPETES_WITH`, `SUBSTITUTES_FOR`, `PARTNERS_WITH` and `FINANCES` require their own dated relationship evidence. None may be inferred from taxonomy proximity.
- Product overlap may create a competitor candidate, but promotion to `COMPETES_WITH` requires explicit issuer evidence or a separately approved market-overlap test.
- Graph traversal and spatial proximity must preserve edge types. The UI must not place a financing partner under customers, a competitor under suppliers, or a shared-driver peer inside a direct value-chain lane.

### 9.4 Spatial-plane rules

- Each company occupies the center of its own spatial plane. Products and services belong inside or immediately around that company hub.
- Upstream suppliers/inputs, downstream customers/channels/end markets, competitors/substitutes, financing/partners and regulations occupy distinct labeled zones.
- A micro-industry may visually house or group multiple company planes, but it does not replace each company's own product and relationship evidence.
- Recursively opening a connected company creates or reveals that company's plane and preserves the typed, dated bridge back to the prior plane.
- Shared economic drivers sit outside company and micro-industry containers. They connect to relevant product, end-market, process or company nodes through typed exposure edges.
- A node with incomplete ingestion must display `boundary entity` or `taxonomy pending`; absence of a company packet must never be represented as absence of products or relationships.

### 9.5 Driver propagation and lead/lag detection

When an Eco Sensor detects a material change in a shared driver, the engine may open affected micro-industry branches for research, but it must evaluate every branch independently:

1. identify the changed driver, metric, direction, magnitude and event date;
2. connect it to specific products, processes or end markets—not merely to broad industry labels;
3. test the economic mechanism, sign, exposure, capacity constraint and expected lag for each company branch;
4. search upstream, downstream, substitutes and competing end markets across micro-industries;
5. compare dated observations to determine whether Company A historically or currently inflects before Company B;
6. distinguish an observed lead/lag relationship from a proposed monitoring sequence; and
7. surface long, short, pair or relative-value candidates only after company-specific materiality and contradiction checks.

The statement `Company A and Company B share an economic driver, but A sees the inflection earlier than B` is a **Hypothesis** until comparable dated observations establish the driver exposure and lead/lag sequence. Shared narrative language, simultaneous price movement or graph proximity is insufficient.

### 9.6 ATKR / HUBB illustrative taxonomy

- The current `TickerUniverse.csv` places ATKR and HUBB in the broad category `Industrials → Electrical Equipment & Parts`.
- A proposed finer map may place ATKR product functions in conduit, raceway, cable management and framing, while placing HUBB product functions in wiring/connectors, grounding/boxes and utility equipment. These labels remain proposed until supported and adjudicated at the product or segment level.
- Data-center buildout may be a shared economic-demand driver across those micro-industries. This shared exposure does not itself make ATKR and HUBB supplier/customer counterparts or direct competitors.
- A sensor at that driver must traverse each product branch separately. The engine must test which company sees orders, backlog, volume, price, capacity or margins change first and whether the later branch is historically and economically supported.

### 9.7 Economic Peer and business-proximity rules

`ECONOMIC_PEER` is a non-commercial graph relationship for companies whose operating signals may confirm, lead, lag or contradict one another because they share one or more underlying economic drivers. It must not be used as a synonym for competitor, comparable company, supplier, customer or statistical price peer.

An Economic Peer record must preserve a multidimensional proximity vector rather than only an opaque composite score:

- `product_overlap`: similarity of products or functional jobs performed;
- `competitor_overlap`: extent of direct contest for the same customer purchase or project scope;
- `shared_end_market_exposure`: overlap in end markets, customer budgets or project types;
- `shared_driver_exposure`: overlap in demand, commodity, policy, capacity or technology forces;
- `direct_value_chain_linkage`: separately evidenced supplier, customer, distributor or contractor connection;
- `geographic_overlap`: exposure to the same relevant regions or regulatory regimes; and
- `observed_lead_lag`: whether comparable dated operating metrics show one company inflecting before the other.

Each dimension stores a value or `unknown`, calculation method, evidence IDs, as-of date and confidence. Values such as `competitor overlap: 25%` or `shared end-market exposure: 75%` must never be displayed as facts unless the denominator, product/revenue mapping and calculation are reproducible. Until then the UI must use qualitative, evidence-bounded states such as `limited`, `partial`, `strong`, `proposed` or `unknown` and identify what has not been measured.

Spatial closeness may be derived from this vector for layout, but layout distance has no independent semantic authority. The UI must expose the dimensions behind closeness and must not allow a visually close node to imply causality or a direct commercial relationship.

### 9.8 Economic Peer confirmation and multi-order lineage

- An observed change reported by one Economic Peer may become a confirmation candidate for another company's driver exposure. It does not automatically become that company's signal.
- Confirmation requires independent observations tied to the same defined driver and comparable direction, period, metric scope and expected transmission sequence. Repeated mentions of one source do not increase confirmation density.
- The engine must distinguish `positive confirmation`, `negative confirmation`, `contradiction`, `substitution pressure`, `shared cost pressure`, `capacity competition` and `no comparable signal`.
- A multi-company confirmation stack—such as demand, orders, backlog and construction activity—must retain each issuer's precise metric and date. Unlike metrics cannot be added together as if they were one measurement.
- A causal lineage begins with the material change and traverses typed mechanisms through drivers, end markets, projects, products, processes, constraints and companies. Economic Peer edges help select independent sensors; they are not themselves causal transmission edges.
- Lead/lag is measured between comparable operating signals, not inferred from filing dates alone. Reporting calendars, fiscal-period differences, acquisitions, backlog duration, price versus volume and guidance versus actual results must be normalized.
- A downstream company remains a Hypothesis until its own evidence confirms the expected change or an approved historical model establishes a sufficiently reliable lag with current causal conditions intact.

Illustrative treatment of the user's example:

`HUBB data-center demand commentary → ETN orders → POWL switchgear orders → PWR electrical backlog → electrical-construction confirmation → potential ATKR conduit/cable-management demand`

This is a proposed sensor-confirmation lineage, not a validated chain in the current frozen dataset. HUBB and ATKR may be Economic Peer candidates through shared data-center/electrical-construction exposure while retaining different micro-industry memberships. Before publication, every observation, plus sign, transmission arrow and lag must be supported separately; ATKR's own later operating evidence must confirm or contradict the propagated Hypothesis.

### 9.9 Homepage deep-lineage eligibility

The company reporting the change is a **sensor**, not automatically the investment destination. Its first-order revenue, orders, backlog, volume or margin observation belongs on the company page and in the evidence packet. It must not occupy a homepage research card merely because management attributed the result to a known theme.

A homepage Hypothesis must satisfy all of the following:

1. Begin with a dated, governed sensor state that satisfies the measurement rules above.
2. Traverse beyond the reporting issuer through at least four typed economic-transmission steps. A direct supplier/customer relationship counts as only one step and graph adjacency does not count as causal proof.
3. Terminate at a less-obvious public company, private entity, product, process, capacity constraint, commodity, geography, regulatory exposure or explicitly labeled unresolved frontier. At least one terminal must be two or more economic steps beyond the reporting issuer.
4. State the physical or economic mechanism, direction, date, evidence IDs, materiality status and failure condition for every hop. Unsupported hops remain `conditional`, `unproven` or `unresolved_frontier`.
5. Test both upstream and downstream propagation when economically applicable, including availability benefit versus input-cost harm, channel sell-through versus inventory accumulation, and beneficiary versus casualty branches.
6. Keep the root issuer's reported result as supporting evidence inside the lineage. Do not headline a first-order “positive watch” that merely paraphrases the transcript.
7. Show every applicable terminal-company ticker as a clickable node. Stock-price movement is context only and never validates the causal chain or novelty.
8. If the graph cannot defensibly identify the next company, stop at an unresolved frontier and generate a research task. Never invent a supplier, customer, commodity producer or earnings effect to make the chain longer.
9. Remain a `Hypothesis` until both sides of every thesis-critical relationship, propagation timing, financial materiality, contradiction search and expectations/valuation asymmetry pass the Idea gates.

Homepage ranking prioritizes causal depth, endpoint obscurity, evidence coverage, economic materiality and consensus unawareness. Depth alone is not quality: repeated generic nodes, semantic restatements and unsupported arrows do not increase the hop count.

### 9.10 Triangulated counterparties and recursive frontiers

Companies do not always disclose supplier or customer names. The engine may therefore create a `TRIANGULATED_CANDIDATE` edge when several independent dimensions narrow the plausible counterparty set. A triangulated edge is a governed prediction, not an issuer-disclosed relationship.

Required dimensions are evaluated separately:

1. exact product or component fit;
2. subtype, specification and physical-use fit;
3. micro-industry and end-market fit;
4. geography, capacity and qualification fit;
5. timing consistency with the detected change;
6. counterparty evidence, including the candidate's own filings, transcripts or product documentation; and
7. conflicts such as vertical integration, competitor-only disclosure, incompatible specifications, alternative suppliers or immaterial exposure.

The engine must store the score components, supporting evidence IDs, conflicts, alternatives, as-of date and the next fact needed to resolve every candidate. A triangulation score is a research-ranking score and must never be displayed as a calibrated probability unless it has been validated against a dated holdout set of known relationships.

Candidate tiers are:

- `BROAD_SCREEN`: category or industry resemblance only;
- `PLAUSIBLE_CANDIDATE`: product and at least one additional dimension match, but commercial linkage is absent;
- `HIGH_CONFIDENCE_PREDICTION`: exact product/subtype plus multiple independent dimensions and counterparty evidence match, with no unresolved critical conflict;
- `CONFIRMED_RELATIONSHIP`: direct commercial evidence satisfies the applicable relationship rules. This is not a prediction tier.

Broad industry, shared data-center exposure or a generic material match cannot by itself exceed `BROAD_SCREEN`. A company named only as a competitor cannot be relabeled as a supplier. A `TRIANGULATED_CANDIDATE` on a thesis-critical edge blocks promotion to `IDEA`, regardless of its score.

Expansion is frontier-driven rather than ticker-count-driven. For each affected product, the engine decomposes the bill of materials, manufacturing processes, channels and end markets into branches. Each unresolved branch becomes a dated research task. The next company packet is selected because it can resolve a frontier, not merely because it belongs to the same broad industry. Validated counterparties open their own company planes and the process repeats within configured depth, confidence and cost limits.

The UI and ranking system must report separately:

- `evidenced_causal_depth`: consecutive transmission edges with direct or corroborated evidence;
- `exploratory_depth`: the deepest displayed route including conditional and unresolved edges;
- `frontier_count`: unresolved branches still requiring research; and
- `mapped_node_count`: unique displayed nodes, which is not a hop count.

Parallel branches do not add to causal depth, and a product, its production, its input demand and its possible earnings effect cannot be counted as independent evidence merely because each is displayed in a separate box.