The five named entities Signal Engine creates, stores, and reasons about. Every pipeline step, database table, and UI view is organised around these five objects.
Definition
A discrete, sourced observation of a real-world event that is potentially relevant to an active intelligence environment. The atomic unit of intelligence — extracted by the pipeline, scored for relevance, and stored independently of any downstream interpretation.
Why it exists
To separate observation from interpretation. A signal records what happened with maximum fidelity to its source. What it means for a specific investment thesis, pressure category, or candidate hypothesis is determined separately — and the same signal can serve multiple analytical contexts simultaneously without contaminating the underlying observation.
PE Signal example
"Blackstone acquires a controlling stake in a mid-market healthcare staffing firm at a 12× EBITDA multiple, citing sector consolidation as the thesis." Extracted from a specialist PE trade publication. Relevance score: 9.1.
Wealth Signal example
"UBS reports net new assets of CHF 22bn, driven by UHNW inflows from Asia-Pacific, exceeding analyst estimates by 40%." Extracted from a financial newswire. Relevance score: 8.4.
Where it appears
Brief viewer — as evidence
Live Signals dashboard
signals table
signal_pressures junction
candidate_evidence junction
Definition
A named real-world actor — a firm, fund, institution, person, or index — that appears repeatedly across signals. Entities are extracted from signals and accumulated over time to surface patterns invisible in any individual observation.
Why it exists
Individual signals are data points. An entity accumulating signals across multiple time periods, source types, and pressure categories is a pattern — and patterns are intelligence. Entity memory allows the platform to answer "what is happening around this firm?" rather than "what happened today?"
PE Signal example
"KKR" appears in 14 signals over 30 days: three deal announcements, two LP fundraising signals, four portfolio company operational signals, and five macro pressure signals naming the firm. The accumulation tells a different story than any single observation.
Wealth Signal example
"Julius Baer" appears in 9 signals over 21 days spanning regulatory overhead, advisor attrition, and AUM outflow narratives. The pattern implies structural pressure across multiple dimensions simultaneously.
Where it appears
Live Signals dashboard
entities table
signal_entities junction
Definition
A named structural hypothesis about a market dynamic that Signal Engine is actively watching. A forward-looking claim — not a current fact — that an analyst has decided warrants systematic evidence accumulation. Candidates can be confirmed, suspended, or retired based on evidence over time.
Why it exists
Signal volume is high. Without candidates, analysts must read every signal to find the ones that matter to a specific thesis. Candidates invert this: they define what matters first, then the pipeline accumulates evidence automatically. This shifts the analyst role from reading to reviewing.
PE Signal example
"AI Lab IPO Wave" — hypothesis that leading AI labs will pursue public listings within 24 months, creating a new LP exit pathway and reshaping institutional allocation. Every signal mentioning IPO readiness, secondary liquidity, or institutional AI allocation is automatically evaluated as potential evidence.
Wealth Signal example
"Private Credit Democratisation" — hypothesis that private credit structures are moving into UHNW retail channels, creating allocation competition for traditional fixed income. Evidence accumulates from product launch signals, regulatory approval signals, and advisor adoption signals.
Where it appears
Admin → Candidates
candidates table
candidate_evidence table
candidate_journal table
Definition
A named macro or structural force that systematically influences the intelligence environment. Pressures exist at two levels: a universal library of named forces (environment-agnostic), and environment-specific overlays that define how each force manifests in a particular investment context.
Why it exists
Not all signals carry equal analytical weight. Pressures provide the thematic structure that allows a brief to say "14 of today's signals relate to debt stress at the entity level" rather than presenting undifferentiated volume. They are the connective tissue between signal extraction and brief generation — the mechanism by which raw observations become organised intelligence.
PE Signal example
The universal pressure debt_stress manifests as "Leveraged Credit Distress and Restructuring" — capturing covenant breaches, distressed debt exchange offers, and restructuring mandates. The tagger looks for named entity distress events, not macro credit conditions.
Wealth Signal example
The same universal pressure debt_stress manifests as "Corporate Credit Deterioration and Default Risk" — focused on named bond defaults and issuer refinancing stress relevant to fixed income positioning. Same force, different lens.
Where it appears
Brief — pressure section
Admin → Pressures
pressures table
pressure_fields table
signal_pressures junction
Definition
The synthesised intelligence output generated from the day's signals, organised by active pressures, and written for a specific environment and audience. Not a summary of news — a structured answer to the question: "What changed today that is material to this investment context?"
Why it exists
Raw signals are inputs, not outputs. Analysts need a single structured document that surfaces what is important, filters what is noise, and frames observations in terms of investment relevance. The brief is the product — the reason the pipeline exists.
PE Signal example
A PE brief surfaces today's deal activity, portfolio pressure signals, and fundraising developments — organised by the 11 active pressure categories — with a synthesis layer naming which pressures are intensifying and what the pattern implies for deal pipeline and portfolio risk.
Wealth Signal example
A Wealth brief surfaces regulatory changes, asset management industry shifts, UHNW allocation trends, and macro pressures — written for advisors managing long-horizon family office portfolios, framed in terms of allocation implications rather than trading opportunities.
Where it appears
Brief viewer (index.html)
briefs table
public/briefs/{env}.md
How the five core objects connect and how information flows from external sources to finished brief.
Object Dependency Graph
Information flows downward. Read top to bottom.
External Sources
↓ crawl + extract
SIGNALS
↓ signal_entities
↓ signal_pressures
↓ candidate_evidence
ENTITIES
PRESSURES
CANDIDATES
↓ ↓ ↓ generate-brief synthesises all three
BRIEF
central
Signals are the central object. Every downstream layer — entities, pressures, candidates — derives its data from signals. Nothing is created independently of a signal event.
parallel
Pressures and Candidates are parallel, independent consumers of signals — not a hierarchy. The same signal can simultaneously evidence a pressure and support a candidate hypothesis. These are sibling relationships, not parent-child.
synthesis
The Brief consumes Pressures, Candidates, and Entities simultaneously — not just the latest signals. The brief reflects accumulated intelligence, not only today's activity.
persistence
Entity memory accumulates indefinitely across pipeline runs. Signal, Pressure, and Candidate data is also persistent but re-evaluated each run. The Brief is regenerated every pipeline cycle.
Pipeline Flow
1
Crawl Sources
Fetches content from RSS feeds and web sources defined in the environment config.
crawl-sources.js → data/raw/latest/*.json
2
Extract Signals
Sends raw content to Claude for structured extraction — produces scored, typed signals with summaries and relevance scores.
extract-signals.js → data/processed/signals.json
3
Entity Memory
Upserts signal and entity records to Supabase. Creates signal_entities links. Deduplicates by signal_hash.
update-entity-memory.js → signals, entities, signal_entities
4
Pressure Tagging
Evaluates each signal against all active pressure_fields for the environment via Claude. Only active fields appear in the prompt — retired parent pressures cannot receive tags.
tag-signal-pressures-auto.js → signal_pressures
5
Geo Tagging
Tags signals with geographic exposure metadata — regions, countries, and coverage confidence.
tag-geo.js → signal geo fields
6
Export Summary
Writes pressure summary and evidence JSON to the public data directory for the frontend.
export-pressure-summary.js → public/data/*.json
7
Generate Brief
Synthesises signals, pressure distribution, entity momentum, and candidate evidence into a structured intelligence brief. Persisted to Supabase and the public briefs directory.
generate-brief.js → briefs table, public/briefs/{env}.md
The five dimensions Signal Engine uses to measure quality, maturity, and momentum. Status reflects current build state — not all dimensions are fully operational.
Definition
A 0–1 score assigned at extraction time reflecting how clearly the source material supports the extracted observation. High certainty = direct, primary, unambiguous source. Low certainty = inferred, speculative, or second-hand reporting.
Why it exists
A regulatory filing and a rumour piece are fundamentally different forms of evidence. Signal Certainty allows downstream consumers — the brief, the pressure tagger, the candidate tracker — to weight observations appropriately rather than treating all extractions as equivalent.
PE Signal example
Official deal announcement press release → certainty 0.93. Analyst commentary about a rumoured deal → certainty 0.38. The pipeline captures both; certainty determines how each is weighted downstream.
Wealth Signal example
Central bank rate decision statement → certainty 0.97. Wealth manager market outlook letter citing expectations → certainty 0.52.
Where it appears
signals.confidence — stored
Brief viewer — not yet surfaced
Definition
A structured measure of how strongly accumulated evidence supports a candidate hypothesis. Currently expressed as a qualitative band (Preliminary / Developing / Established). Target design: a 1–10 score derived from evidence count, source diversity, velocity, certainty weighting, and the ratio of supporting to contradicting evidence.
Why it exists
A candidate with 3 signals from one low-certainty source is in a different epistemic state than one with 28 signals from 9 sources across 45 days. Conviction makes this difference explicit and operational — preventing premature action on thin evidence and surfacing which hypotheses have earned analytical attention.
PE Signal example
"AI Lab IPO Wave" at Conviction 7 — 22 supporting signals from 8 independent sources, strengthening velocity, zero contradictions over 60 days. "GP-Led Secondary Consolidation" at Conviction 2 — 4 signals from a single source, no trend established.
Wealth Signal example
"UHNW Liquidity Preference Shift" at Conviction 5 — 11 signals across 4 sources, stable velocity, 2 low-certainty contradictions. Analyst review appropriate before acting on the hypothesis.
Where it appears
candidates.confidence_band — current
Admin → Candidates
1–10 numeric score — planned
Definition
The rate at which new evidence is accumulating for a candidate, expressed as the ratio of observations in the last 7 days versus the prior 7 days. Three states: strengthening (>1.25×), stable (0.75–1.25×), weakening (<0.75×).
Why it exists
A candidate with 30 total evidence items but no new signals in 21 days is structurally different from one with 12 total items and 8 in the last 7 days. Velocity identifies which candidates represent live, accelerating dynamics versus historical patterns that have already played out.
PE Signal example
"Sector Roll-Up Activity" shows velocity 2.1× — prior 7 days had 5 observations; current 7 days has 11. An emerging consolidation wave is accelerating and warrants increased analyst attention this week.
Wealth Signal example
"Private Credit Democratisation" shows velocity 0.4× — signal flow has dropped significantly after a burst of activity. The dynamic may be pausing or source coverage may have shifted.
Where it appears
candidates.trend
calcTrend() in tag-candidates.js
Admin → Candidates
Definition
The directional change in Candidate Conviction over time. Distinct from Evidence Velocity (which measures signal volume rate) because Conviction Trend incorporates source quality and contradiction weight — not just observation count.
Why it exists
A candidate can be accumulating evidence at high velocity while simultaneously becoming less convincing — if new signals are low-certainty or contradictions are mounting from primary sources. Conviction Trend surfaces this divergence, preventing analysts from being misled by apparent momentum that is not analytically substantive.
PE Signal example
"Healthcare Platform Consolidation" shows high velocity (10 new signals this week) but a downward conviction trend — 4 of the 10 are contradictions from primary sources, and 3 supporting signals are from a single low-certainty outlet. More signals, less conviction.
Wealth Signal example
"Tokenised Asset Adoption" shows declining conviction trend despite stable velocity — signals are accumulating but increasingly from advocacy sources rather than transactional evidence of actual adoption.
Where it appears
Not yet built
Target: candidates.conviction_trend
Requires source_tier classification first
Definition
The directional change in signal frequency for a named entity — whether a firm, fund, or person is appearing more or less often in the intelligence corpus over time. High momentum means increasing relevance; declining momentum means the entity is fading from active coverage.
Why it exists
Entity Momentum surfaces who is becoming important before that importance is widely acknowledged. A firm appearing in 3× more signals this month than last is a forward signal in itself — regardless of what any individual signal says. Early momentum detection is one of the highest-value capabilities Signal Engine can provide.
PE Signal example
"Thoma Bravo" shows entity momentum of +180% over 30 days, driven by a portfolio exit, a new fund close, and two add-on acquisitions in rapid succession. This concentration warrants analytical attention before the firm's prominence appears in consensus narratives.
Wealth Signal example
"Pictet" shows entity momentum of −40% — appearing significantly less than in the prior period following a burst of regulatory activity. A downward pattern worth monitoring for structural explanations.
Where it appears
Live Signals dashboard — client-side
Not stored in database — computed on render
How the platform is structured — the environment model, source universe, and config/database split that governs all operational decisions.
Definition
An Environment is a named intelligence context that defines a distinct audience, source universe, pressure overlay, and brief format. All pipeline runs are scoped to a single environment. The same macro event produces different intelligence in different environments because the analytical frame differs.
Why it exists
A Federal Reserve rate hold means something different to a PE firm managing leverage ratios than to a family office managing bond duration. The environment model allows Signal Engine to produce intelligence that is contextually accurate rather than contextually neutral. A neutral brief is a less useful brief.
PE Signal
Sources: specialist PE trade press, deal databases, portfolio company news. Pressure overlay: 11 active fields tuned for deal execution risk, portfolio company operations, and LP dynamics. Brief audience: PE deal teams and portfolio management.
Wealth Signal
Sources: wealth management trade press, central bank publications, UHNW sector news. Pressure overlay: 9 active fields tuned for long-horizon portfolio risk, advisor dynamics, and cross-border wealth structuring. Brief audience: family office advisors and relationship managers.
Where it appears
environments table
ENVIRONMENT_ID env var
config/*.json
Environment switcher — header
Definition
The complete set of external sources the pipeline monitors for a given environment. Each source has a type, update frequency, and relevance to the environment's pressure universe. Source quality directly determines intelligence quality — the pipeline can only detect pressures covered by its source universe.
Why it exists
A pressure with no relevant sources will never receive tags regardless of how well its field description is written. Understanding the source universe is therefore a prerequisite for understanding which pressures are genuinely detectable versus theoretically active. Source tier classification — distinguishing primary from secondary sources — is the next planned capability.
PE Signal
Specialist PE dealflow publications, LBO deal announcement feeds, portfolio company press release aggregators. Each source type has a different signal density and pressure coverage profile.
Wealth Signal
Wealth management trade press, central bank communications, regulatory announcement feeds, UHNW industry publications. Coverage of global regulatory changes is strong; coverage of private client flows is structurally limited by data availability.
Where it appears
config/sources-{env}.json
crawl-sources.js
Source tier classification — planned
Definition
A strict separation between static configuration (source lists, environment definitions, tone profiles) stored in config/*.json and dynamic operational state (signals, entities, briefs, pressure tags) stored in Supabase. Config is version-controlled and copied to public/config/ at the top of every pipeline run — overwriting any manual edits.
Why it exists
Mixing configuration and data creates fragility. A bad pipeline run can corrupt configuration; configuration changes can create inconsistent data states. The split ensures the source of truth for "how the pipeline is configured" is always in version control — not in database state that can drift.
Config layer
config/sources-pe-signal.json — source list. config/environments.json — environment metadata. These are canonical. Edits to public/config/ are silently overwritten on every pipeline run.
Database layer
Supabase holds all signals, entities, pressures, pressure_fields, candidates, briefs, and prompt context blocks. The pipeline reads these at runtime — they are operational state, not configuration, and are not version-controlled.
Where it appears
config/*.json
src/lib/config-loader.js
syncPublicConfig() in run-pipeline.js
The two-tier pressure architecture: a universal library of named forces, and environment-specific overlays that define how each force manifests in a particular investment context.
Definition
A curated registry of named macro and structural forces that apply across investment contexts — environment-agnostic by design. The canonical reference for what forces exist. Environment overlays define how each force manifests specifically.
Why it exists
Without a universal layer, pressure naming diverges across environments and becomes inconsistent over time. The library ensures that debt_stress means the same underlying force in PE, Wealth, and any future environment — even if its manifestation differs. It is the shared language that makes cross-environment intelligence comparable.
Registry composition
54 pressures defined. 36 ACTIVE (receiving tags), 13 DEFERRED (valid concept, insufficient source coverage to activate), 4 RETIRED (no longer analytically useful). The library grows deliberately — new pressures added only when a clear analytical gap exists.
Domains
Pressures span macro, credit, geopolitical, regulatory, technology, and sector-specific domains. Domain classification governs brief organisation and pressure grouping in analytics views.
Where it appears
pressures table
Admin → Pressures
Definition
An Environment Overlay (stored as a pressure_field record) is a named, described instance of a universal pressure within a specific environment. It defines the field name, field description, and weight multiplier that the tagger uses when evaluating signals. The same universal pressure has a distinct overlay in each environment.
Why it exists
The tagger prompt is constructed from pressure_field descriptions — not from the universal pressure description. This allows the same underlying force to be described with environment-specific analytical framing without duplicating the pressure registry. The overlay is where environment-specific intelligence expertise lives.
PE Signal
trade_fragmentation → "Tariff and Trade Policy Impact on Deals and Portfolio": tariff escalation, export control expansion, or bilateral trade restriction with direct commercial consequences for PE deal theses or portfolio company operations. Weight: 1.1×.
Wealth Signal
trade_fragmentation → "Trade Policy Realignment and Asset Exposure": tariff escalation, export controls, or trade agreement breakdown affecting equity valuations, commodity exposure, or sector allocation in UHNW portfolios. Same force, different lens. Weight: 1.1×.
Where it appears
pressure_fields table
tag-signal-pressures-auto.js — tagger prompt
Admin → Pressures
Definition
Every pressure moves through a defined lifecycle. Status governs whether the pressure receives new tags and appears in briefs. Only ACTIVE pressures with ACTIVE pressure_fields contribute to pipeline output.
| Status | Meaning | Receives tags |
| ACTIVE | Analytically relevant, source-covered, receiving tags via active pressure_fields | Yes |
| DEFERRED | Analytically valid but source coverage is insufficient to produce reliable tags | No |
| RETIRED | No longer analytically useful — all environment overlays must be deactivated | No |
Integrity invariant
A pressure_field can only receive tags if both the pressure_field and its parent pressure are active. The tagger filters on pressure_fields.active but does not automatically filter on pressures.active. Environment overlays must be explicitly deactivated when a parent pressure is retired. This invariant is enforced via database migration, not application code.
Definition
New pressures are activated in staged waves rather than all at once. Each wave is validated before the next starts. This controls tagging noise, ensures each new field description is analytically clean, and gives analysts time to confirm that activated pressures are producing genuine signal before expanding the pressure universe further.
Why it exists
Activating many pressures simultaneously creates ambiguity that is difficult to diagnose — overlapping definitions, boundary collisions, and false positives compound each other. A staged model makes problems attributable. If a new pressure produces noise, the noise is isolated to that pressure and correctable without disrupting the entire tagging system.
Wave 1A — complete
market_consolidation, trade_fragmentation, debt_stress, sanctions_escalation — activated 2026-06-17 across PE Signal and Wealth Signal. Validation checklist prepared; review pending next pipeline run.
Wave 1B — next
valuation_compression, cybersecurity_threat — held until Wave 1A validation confirms clean tags and acceptable overlap ratios.
Where it appears
pressure_fields.active flag
supabase/migrations/ — each wave is a migration
The operating principles that govern design decisions, feature priorities, and analytical choices. These are constraints, not aspirations.
The core distinction
Information is what happened. Intelligence is what it means for a specific decision. Signal Engine produces intelligence, not information. A tool that produces more information than an analyst can act on has not made the analyst more effective — it has made them slower.
What this means in practice
Every pipeline component should filter and frame, not merely collect and present. The brief is not a news digest. Pressures are not topic tags. Candidates are not saved searches. Each layer adds analytical structure — it interprets, weights, and contextualises. If adding a feature increases output volume without increasing decision-relevant structure, it is not aligned with this principle.
A news aggregator. Signal Engine does not aim to surface everything — it aims to surface what matters to a specific investment context.
A sentiment analyser. Sentiment is a crude proxy for investment relevance. Signal Engine extracts structured observations, not polarity scores.
A research report generator. The brief assumes the analyst already understands the domain. It does not explain macroeconomics.
A decision engine. Signal Engine produces evidence and surfaces patterns. The analyst closes the gap to decisions. The platform does not recommend actions.
A comprehensive data platform. Signal Engine monitors a curated source universe, not the internet. Coverage is intentional, not exhaustive.
A structured early-warning system — surfacing signals before they become consensus narratives.
A hypothesis tracker — accumulating evidence for and against named investment theses over time.
A pressure monitor — maintaining a live view of which macro forces are intensifying in each investment environment.
An entity intelligence layer — tracking which named actors are gaining or losing prominence in the intelligence landscape.
The principle
A brief with 12 high-certainty signals organised under well-defined pressures is more valuable than one with 47 low-certainty signals under ambiguous categories. Source count, signal count, and pressure count are not success metrics. Conviction is — the degree to which the platform's output allows an analyst to act with more confidence than they had before reading it.
What this means for pressure activation
Pressures are activated only when their field descriptions are clean enough to produce unambiguous tags. A pressure producing 30 tags with 40% false positives is worse than no pressure — it creates noise that must be manually filtered. The wave activation model exists to enforce this standard.
What this means for source selection
Sources are selected for signal density within a specific environment — the proportion of content genuinely relevant to the environment's pressure universe. A high-volume source with low signal density is a cost centre, not an intelligence asset.
The principle
Signal Engine is an intelligence augmentation tool, not an intelligence replacement. The pipeline surfaces observations and measures patterns. The analyst determines what patterns mean, which candidates deserve attention, and when evidence justifies action. This division is intentional and permanent.
What the pipeline decides
Which signals to extract. Which pressures they evidence. Whether candidate evidence is supporting or contradicting. What the evidence velocity trend is. These are measurement decisions — they require precision but not judgment.
What the analyst decides
Which candidates are worth watching. When conviction is sufficient to act. Whether a pressure pattern implies portfolio risk or opportunity. How intelligence translates to recommendation. These are judgment decisions — and Signal Engine does not make them.