# 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.

### 9.11 On-demand sensor-to-product lineage

The interactive lineage finder is deliberately ad hoc. Company planes, products, inputs, dated sensors and evidence are precomputed; a candidate lineage is generated only after an analyst selects a ticker, dated Eco Sensor and product. This avoids indiscriminate all-pairs lineage synthesis.

- The first retrieval stage may use deterministic product/function and company-level input similarity across the active frozen cohort. It must make no paid model call unless the UI and cost ledger explicitly say otherwise.
- Product/capability similarity, embedding similarity and company-level input compatibility are candidate-generation signals only. They do not prove that a candidate supplies, buys from, competes with or benefits from the selected issuer or product.
- `match_score` is a within-cohort research-ranking score, not a probability, confidence percentage or expected stock return.
- Direct accepted relationships use solid edges. Extracted but unaccepted relationships use dashed edges. Candidate-only connections use dotted edges and the explicit label `connection unproven`.
- Every candidate must expose its matched products and evidence IDs. A product-specific supplier claim requires product-specific counterparty or independent evidence; a company-wide raw-material disclosure is insufficient.
- Cached results are keyed by dataset/as-of version, ticker, sensor, product and result limit. New or corrected evidence must invalidate the affected cache key.
- Candidate-only output cannot be promoted to an `Idea`, stored as an accepted relationship, or treated as factual lineage without the applicable bilateral, materiality, contradiction and timing gates.

### 9.12 Public procurement and reverse-disclosure enrichment

For project-driven issuers, authoritative customer procurement records, bid awards, permits and reciprocal company filings may enrich the company plane after the issuer packet is decoded.

- A named award may establish the buyer, seller, product scope, project, award date and bid-specific competitors. An authorization ceiling is not revenue, backlog, shipment timing, margin or economic materiality.
- A co-bidder is a competitor for that solicitation only unless broader evidence establishes market-wide competition.
- A contract vehicle establishes purchasing eligibility, not an order or customer revenue.
- Reverse disclosure can corroborate a relationship, but its date and the disclosing party must remain visible. Stale reverse evidence stays off the current plane pending refresh.
- Historical agreements are stored as `historical` or `superseded`; they never become current supplier/customer edges merely because the parties still exist.
- Supplier portals, conflict-minerals lists, approved-source classes and product compatibility do not identify a direct supplier. If no current named supplier is found, report zero and preserve the frontier.
- Public-source enrichment is additive. It may not overwrite the frozen issuer extraction or bypass analyst review and Idea-promotion gates.
- Every newly admitted ticker must pass the cohort reverse-EDGAR stage after its issuer packet is checkpointed. The stage searches exact SEC legal-name mentions in third-party 10-K, 10-Q and 8-K filings, excludes the subject issuer's own CIK, preserves the filing date/registrant/context and is resumable by ticker and document.
- Exact-name search is intentionally the high-precision first pass. Aliases, subsidiaries, product marks and project identifiers may be searched only from a dated controlled registry so shortened names do not silently broaden the candidate universe.
- Reverse-search limits are coverage boundaries, not negative evidence. A capped search, unexamined result, failed download or absent exact-name hit must remain explicitly visible as such.
- Automated reverse-search classifications are queue routing only. Every record remains `unadjudicated_candidate`; no reverse-search stage may create an accepted edge, alter a current spatial plane, or produce an Idea/Hypothesis without the normal identity, direction, date, contradiction and materiality adjudication.
- The analyst review queue must deduplicate repeated disclosures by subject, external registrant and proposed relationship class, retain up to three underlying filing records, and cap how many candidates a single ticker can contribute to a benchmark sample.
- Queue scores prioritize review order only; they are never probabilities or confidence scores. `Accept`, `Reject`, `Correct` and `Defer` decisions must be stored with candidate ID, reviewer, time and optional notes.
- Accepting a queue candidate records analyst judgment but does not publish an edge. A separate promotion step must validate required fields, temporal state, evidence identity, reciprocal direction and contradictions before writing the current graph.

### 9.13 Physical product-form and production-stage compatibility

A shared commodity or material word never establishes a supplier path. Before any product/input match enters causal traversal, the engine must verify that the candidate product occupies a compatible physical form and production stage.

- Raw feedstocks, resins, pellets, chemicals, gases, alloys and other process inputs cannot be matched to finished pipe, valves, conduit, machinery, installation or maintenance services merely because the same material name appears in both descriptions.
- The engine compares the disclosed input with an individual candidate product, not an aggregate company product vocabulary. The selected product and its evidence must remain attached to the proposed edge.
- Material transformation must be explicit. For example, `PVC/HDPE resin -> finished PVC/HDPE pipe` is not a supplier match; `decant oil -> generic oil-and-gas equipment` is not a supplier match; and `natural-gas consumption -> gas-system installation services` is not a supplier match.
- Functionally distinct components cannot be joined by generic terms such as `linear`, `component`, `equipment`, `material` or `system`.
- A form-compatible result remains `unproven` until counterparty or independent commercial evidence establishes supplier identity. A form-incompatible result is excluded from traversal rather than merely given a lower score.

### 9.14 Causal-review learning and correction safety

- Repeated analyst decisions must be collapsed into stable transition rules so the same company pair/mechanism is not learned multiple times from different sensor cards.
- A physical input cannot match installation, construction, engineering, maintenance, deployment or another service capability. A component requirement cannot match a complete system unless the candidate separately discloses that component.
- Shared-driver transmission must fit the displayed product branch on both sides. Broad mining/metals, construction, industrial or energy membership cannot create a causal hop by itself.
- Distributor, OEM, contractor and integrator roles do not imply transaction direction. Complementary systems may share demand or be co-deployed without either company supplying the other.
- `Correct mechanism` invalidates the original traversable edge. Analyst prose may not be traversed until it is normalized into an explicit source, target, causal type, direction, sign and evidence status. Until then it remains a withheld correction frontier.
- Exact analyst rejections are deterministic exclusions for the matching transition. Exact acceptances mean `retain for further validation`, not confirmed causality or Idea approval. Deferred transitions remain visibly unresolved.
- New paths created after a rule-driven rebuild are labeled `UNREVIEWED_NEW_CANDIDATE`; prior review of one transition cannot be presented as review of every other transition in the path.

### 9.15 Terminal validation and sign discipline

- A retained causal path must be tested against the terminal company's own latest stored filings and transcripts before it can become a valid Hypothesis. Corpus coverage is not confirmation; the terminal packet must contain evidence relevant to the displayed product branch or economic driver.
- Propagate the changed economic variable, not merely the source ticker's positive or negative label. A margin decline, resource transfer, acquisition effect or segment-mix change cannot be relabeled as end-market demand without direct evidence of that demand change.
- Direction and branch must remain consistent from the observed sensor through every hop. A decline caused by resources moving into a growing branch is not evidence that the growing branch weakened.
- Independent confirmation of a shared driver supports a shared-driver Hypothesis; it does not mean one reporting company caused another company's result and it does not establish a supplier/customer relationship.
- Terminal materiality must be measured separately from source materiality. Product share, terminal revenue, gross profit, EPS sensitivity, capacity and expected lag cannot be inferred from source-company growth percentages.
- Every dossier must test stored contradictions, substitution, inventory, capacity and timing evidence and state when expectations/priced-in evidence is unavailable.
- Terminal-validation outcomes are `KILLED`, `RESEARCH_FRONTIER`, `VALID_HYPOTHESIS` or `IDEA_ELIGIBLE`. `IDEA_ELIGIBLE` is not publication; the independent challenge and manual publication gates still apply.
- A killed sensor-path pair cannot re-enter traversal unchanged. A route containing both a valid sensor and a killed sensor must show both decisions; route-level survival may not conceal the invalid sensor.

### 9.16 Orchestrated daily workflow

- `eco_pipeline.py` is the governed entry point. Every onboarding, daily update, affected rebuild and thesis refresh must have a stable run ID, atomic stage ledger, explicit status and reproducible artifact paths.
- Daily processing is ordered: retrieve -> normalize/hash/chunk -> embed changed chunks -> extract company candidates -> reverse search -> sensor-only overlay -> Eco Sensor diff -> affected neighborhood -> multihop synthesis -> causal rules -> terminal validation -> Hypothesis overlay.
- Newly extracted relationships and products never enter daily propagation before relationship adjudication. New dated sensors may propagate only over the last published accepted/corrected graph.
- Ingestion is not a change. An eligible Eco Sensor requires a recognized economic state, event date, measurement and resolvable evidence ID. An identical sensor hash is a no-op.
- When no eligible sensor changed, the run must end `COMPLETE_NO_MATERIAL_CHANGE` without regenerating or republishing causal paths.
- Reprocessing is affected-root only unless an explicit full rebuild is requested. Reverse traversal may identify context but cannot reverse the economic direction of a commercial edge.
- External retrieval and paid model stages require explicit runtime authorization and retain the existing API throttles and database cost reservations. A missing authorization or incomplete batch becomes a visible resumable waiting state.
- Automatic website publication is limited to `VALID_HYPOTHESIS` overlays. The overlay is a separate rollback unit and cannot mutate relationship edges. `IDEA_ELIGIBLE` still requires an independent manual publication decision.
- Concurrent orchestrators are prohibited. A workflow lock and atomic file replacement must protect canonical candidate, dossier and Hypothesis artifacts.

## 10. MVP39 corpus, vector, access and spending governance

These rules govern the approved 39-company `Industrials -> Electrical Equipment & Parts` build. They constrain implementation; they do not weaken any evidence, momentum, taxonomy or Idea gate above.

### 10.1 Frozen cohort and boundary control

- Cohort membership is frozen from the supplied `TickerUniverse.csv` snapshot and recorded with row identity and file hash before retrieval.
- An extracted out-of-cohort ticker or organization is a `boundary entity`. It may be displayed as an unresolved frontier but receives no full packet or paid processing unless a later approved cohort change admits it.
- Missing documents, unavailable transcripts and provider errors are coverage states, never negative evidence about a company or relationship.

### 10.2 Embedding and retrieval firewall

- Semantic similarity means only that passages may be relevant. It cannot establish identity, supplier/customer status, competition, causality, sign, timing, materiality or an investment conclusion.
- Every vector row must resolve to an immutable source document and chunk record with exact text hash, source dates, locator and embedding model/version.
- Re-embedding creates a new version or run; it must not silently overwrite the evidence lineage used by an existing edge or thesis.

### 10.3 Shared PostgreSQL access

- MVP39 objects live only in `eco_electrical_mvp39` unless an approved migration says otherwise.
- Use the existing Polytrade developer identity and shared-access conventions. Do not create an exclusive user, revoke another user's privileges, change unrelated ownership or write outside the MVP39 schema.
- Migrations are idempotent, versioned and auditable. Destructive migrations, source deletion, vector replacement and schema drops require separate explicit approval and a verified backup/rollback path.
- Database credentials and provider keys never enter source files, browser payloads, generated reports, model prompts or logs.

### 10.4 Cost enforcement

- The full MVP39 external API/model hard cap is $50. Before each paid request, reserve its worst-case cost atomically in the run ledger; refuse the request if the reservation would cross the cap.
- Reconcile reservations to actual input, cached-input and output tokens after completion. Failed, truncated and retried requests still count at their actual charged amount.
- No transcript subscription, entitlement upgrade, historical backfill, automatic boundary expansion or alternative paid data source is authorized within this approval.
- Prefer local deterministic parsing, hashing, deduplication, taxonomy screening and candidate generation. Model spend is reserved for passages and causal decisions where it adds measurable value.

### 10.5 Publication and status

- Database presence is not acceptance. Extracted records begin as candidates and must preserve `proposed`, `accepted`, `corrected`, `rejected`, `stale` or `superseded` status.
- Company planes must distinguish direct evidence, triangulated candidates, broad screens and unresolved boundaries visually and semantically.
- A multi-hop path must expose evidence status for every hop. One unsupported critical hop keeps the complete card a `Hypothesis` and blocks `Idea` promotion.
- Production publication, background scheduling and replacement of the frozen MVP25 site are separate actions requiring their own verification and explicit scope.

### 10.6 Source-centric commercial direction

- New commercial edges use unambiguous source-centric predicates. `SELLS_TO` means the source issuer sells a product or service to the target. `BUYS_FROM` means the source issuer purchases an input, product or service from the target.
- The labels `CUSTOMER_OF` and `SUPPLIES` are prohibited in a traversable MVP39 graph unless their subject/object direction is explicitly defined. Legacy or model-produced occurrences must preserve the original label, undergo evidence-linked direction resolution, and become `SELLS_TO`, `BUYS_FROM` or `UNRESOLVED_COUNTERPARTY` before traversal.
- Phrases such as `customer`, `supplier`, `sales to`, `purchases from`, `provides to` and `supplied by` must be interpreted from the grammatical subject and economic transaction. A target's role must not be copied into a predicate without checking direction.
- A company cannot be its own commercial counterparty. If a named organization is paired with the source ticker, quarantine the ticker resolution while retaining the named entity and evidence for review.
- Direction normalization does not accept a relationship. The normalized edge remains `proposed` until its identity, transaction type, date and evidence are reviewed. A model confidence value is a research-ranking score, not a calibrated probability.
- After explicit analyst adjudication in a source/target workbook, `SOURCE CUSTOMER_OF TARGET` normalizes to source-centric `SOURCE BUYS_FROM TARGET`, and `SOURCE SUPPLIES TARGET` normalizes to `SOURCE SELLS_TO TARGET`; the submitted predicate and normalization warning remain in the audit artifact. A reviewed mapping to a valid external/foreign ticker absent from `TickerUniverse.csv` may be retained as a named non-traversable boundary entity, but it cannot become an admitted company plane or a cross-company traversal edge until universe admission and entity resolution pass.

## 11. MVP114 adjacent-industry expansion governance

- The approved cohort is exactly the hash-locked 114-company manifest generated by `mvp114_manifest.py`: 39 Electrical Equipment & Parts, 21 Industrial Distribution, 38 Engineering & Construction, 15 Metal Fabrication, and AVAV. Extracted boundary names do not authorize recursive ingestion.
- MVP39 is immutable baseline evidence. Reusing one of its documents, chunks, vectors, edges, sensors, or extraction outputs must retain original document IDs/hashes, dates, model/run version, evidence status, and analyst decision. Never silently re-extract or present reused evidence as newly observed.
- MVP114 data lives only in `eco_adjacent_mvp114` and its named artifact/private directories. Do not overwrite `eco_electrical_mvp39`, change the running local dataset, or publish to AWS until the new benchmark passes its gates.
- Broad sector, broad industry, micro-industry adjacency, shared end-market exposure, or embedding similarity is candidate-generation context only. None establishes a commercial, competitive, causal, lead-lag, or earnings relationship.
- Cross-industry paths must use typed economic mechanisms: product/input flow, project sequence, distribution channel, production constraint, substitution, commodity exposure, regulatory transmission, or independently measured shared demand. Each traversed hop retains direction, sign, date, lag, evidence IDs, evidence class, conflicts, and status.
- Synthesis must be bounded and hierarchical. First evaluate company planes and micro-industry/product clusters; then join only evidence-preserving frontier candidates across clusters. A summary generated from a cluster is not itself evidence for a later hop.
- Prioritize the 75 new packets by their ability to resolve a dated MVP39 frontier, not by market capitalization or model familiarity. Missing evidence creates a research frontier, not a guessed counterparty.
- New causal or investment outputs default to `Hypothesis`. `Idea` requires reciprocal/counterparty confirmation for every thesis-critical commercial link, validated timing and materiality, contradiction and alternative tests, and all existing Rules.md Idea gates.
- The incremental external-cost hard stop is $18 and the combined MVP39-plus-MVP114 stop is $23.8928. Reserve worst-case cost atomically before paid calls. Unused money under the older $50 cap cannot be consumed by this expansion.
- Benchmark success is measured by novel multi-hop quality, evidenced depth, frontier resolution, sampled precision, and endpoint obscurity. Ticker count, mapped-node count, exploratory depth, or a larger-looking graph cannot substitute for those measures.

### 9.17 Cohort expansion and effort-specific budgets

- Expansion follows reviewed graph frontiers and product/micro-market adjacency, including relevant companies outside Industrials. Broad sector or industry membership alone is never evidence of a relationship.
- Multi-company runs require a hash-locked manifest derived from the current `TickerUniverse.csv`. Duplicate tickers, count mismatch, ticker mismatch, universe-hash drift or cohort-hash drift stop the run before retrieval.
- Expansion ranking scores are not probabilities. A selected company remains outside the reviewed graph until its packet and proposed edges pass adjudication.
- The 2026-09-14 pilot uses `recursive_expansion_wave1_5usd`. Embedding and extraction atomically share its `$5.00` ceiling; the CLI refuses a higher cap.
- Retries reuse the same run ID and request-ledger keys. They may poll or load an existing request but cannot create a duplicate charge.
- Expansion cannot auto-publish a relationship, Hypothesis or Idea. New relationships wait for review; dated sensors traverse only the last accepted/corrected graph.

### 9.18 Additive cohort publication and review inheritance

- A cohort expansion publishes as a new additive dataset and never overwrites the preceding reviewed graph. The publication records base-artifact and decision-ledger hashes so rollback and reproduction remain possible.
- `Accept`, `Correct` and `Map` may publish a current relationship only after ticker resolution, source-centric direction, temporal state and evidence IDs pass deterministic validation. Ambiguous predicates, out-of-universe ticker mappings, self-edges and incomplete corrections are quarantined outside traversal.
- Historical decisions remain historical even when accepted. They cannot appear on the current company plane or participate in Eco propagation.
- A relationship review cannot publish an investment Idea. It may change the graph available to later synthesis, but every generated path independently passes causal-hop review, terminal validation and the full Idea gate.
- Review inheritance is exact-transition and exact-route only. A new candidate containing a previously reviewed hop is not a reviewed path. It must display `UNREVIEWED_NEW_CANDIDATE` or the applicable partial/deferred state until every thesis-critical hop is adjudicated.
- Publication metrics distinguish incremental effort cost from cumulative corpus cost. Deterministic promotion, traversal, Excel export and terminal validation record zero paid-model cost when no paid call occurs.

### 9.19 Causal-review completeness and expansion gating

- Analyst causal confidence is optional. When supplied it must be numeric from 0 through 100; a blank value, especially on Reject or Defer, is valid and must not be invented or imputed.
- A completed path decision does not override its hop decisions. Any rejected thesis-critical hop kills that candidate; corrections remain non-traversable until normalized; deferred hops keep the route at a research frontier.
- Exact hop decisions may constrain identical transition signatures in later synthesis, but newly assembled routes remain unreviewed unless all of their critical transitions are covered and sign/branch consistency is preserved.
- Causal rulebooks are cumulative across cohort waves. A new review inherits every non-overlapping prior exact-transition exclusion, correction, defer and acceptance; the latest analyst decision may supersede the same exact signature only with both versions and the supersession reason retained in the audit artifact. Recompiling from a filtered candidate set must never silently erase older exclusions.
- A larger cohort is authorized only in bounded waves selected to resolve identified graph frontiers or provide explicit controls. High rejection rates require applying the learned exclusions before the next wave; they do not justify lowering evidence thresholds.
- Sector completion is an operating objective, not an evidence claim. Every newly ingested company remains a candidate plane until its relationships are adjudicated, and no wave may publish an Idea automatically.
- The interactive graph is a view over governed records, never a new inference layer. Accepted/corrected current edges render as solid; proposed or unresolved edges render as dotted; rejected, inactive and historical edges are excluded from the current overview. Search, clustering, proximity and visual density cannot upgrade evidence status or imply causality.