How Y2 Works

Y2 is easiest to understand as an intelligence assembly line.

A user starts with a profile: a company, market, region, risk theme, supplier, asset class, incident type, or operating question they care about. Y2 turns that profile into a repeatable workflow that researches the world, organizes the evidence, writes a report, extracts signals, and feeds the durable facts back into an intelligence graph.

The important part is not that Y2 writes a brief. Lots of tools can summarize text. The important part is that Y2 keeps track of where every useful claim came from, what kind of evidence supports it, how it relates to other entities, and whether it should become part of the broader ontology.

At a high level, the system looks like this:

That is the short version. The longer version is below.

The Profile Is the Contract

A Y2 profile is not just a saved search. It is the operating contract for a recurring intelligence workflow.

The profile defines the topic, schedule, audience, research preferences, delivery settings, and optional style or branding. Internally, the profile gives the engine enough context to answer a practical question:

What changed, why does it matter, and what should someone do next?

That question shapes the rest of the pipeline. The engine is designed to produce useful intelligence, not generic coverage.

The Durable Workflow

When a profile runs, Y2 starts a durable workflow. The workflow coordinates the major stages:

1. Generate the report.
2. Optionally create audio.
3. Queue enrichment and extraction.
4. Deliver the report to subscribers.
5. Update profile state.
6. Schedule the next run.

Some stages are critical. Delivery, for example, needs stronger retry behavior because subscribers are waiting for the output. Other stages are useful but non-blocking. Audio, extraction, and graph enrichment can fail or retry without preventing the report itself from reaching the user.

That split matters. Intelligence systems should degrade gracefully. If one model call, enrichment pass, or secondary channel has a bad day, the whole pipeline should not collapse.

RLM: Research by Decomposition

Y2 uses Recursive Language Model research, or RLM, as the report generation pattern.

Instead of asking one model to answer one broad prompt, the engine breaks the topic into smaller researchable parts. It starts with the main topic, gathers current source material, identifies subtopics, researches those subtopics in parallel, and then performs one synthesis pass over the full findings set.

In simple terms:

The system intentionally favors breadth before depth. That keeps the workflow fast enough for scheduled delivery while still giving the model multiple angles on the same operating question.

It also avoids the common failure mode of open-ended agent loops. Y2 does not let research wander forever. It gathers enough evidence, preserves the source trail, and moves into synthesis.

Findings and Source Aggregation

Before the final report exists, Y2 has a findings layer.

This layer is where search results, source excerpts, subtopic findings, source freshness checks, deduped URLs, and usage metadata are brought together. Think of it as the analyst's evidence folder before the memo is written.

The aggregation step has a few jobs:

• Keep direct findings and subtopic findings together.
• Remove duplicate sources.
• Prefer current, relevant material.
• Keep source references attached to claims.
• Trim the evidence set when it gets too large.
• Preserve enough context for the final synthesis step.

This is where Y2 starts to become more than a summarizer. The final report is not generated from one blob of web text. It is generated from an organized, bounded, source-aware findings document.

Synthesis: Turning Evidence Into a Brief

Synthesis is the stage users recognize most clearly. It produces the report.

The synthesis step uses the profile, findings, source list, prior context, and formatting rules to produce a structured brief. The output is designed for humans first: a bottom line, key findings, analysis, outlook, and citations.

But the report is also designed for machines.

Alongside the readable brief, the engine can produce structured signal objects: action or decision hypotheses that describe what the report may imply. A signal is not treated as ground truth. It is a decision-support artifact with a domain, priority, confidence level, evidence URLs, subjects, and an action type.

Examples of signal shapes include:

• Monitor a supplier or region.
• Patch or upgrade exposed software.
• Hedge against commodity or currency movement.
• Escalate an operational risk.
• Defer a decision until a policy change becomes clearer.

Signals are the bridge between a report someone reads and a workflow another system can use.

Event Provenance

After the report is generated, Y2 can extract structured events from the report text.

An event is a discrete thing that happened, is happening, may happen, or is being analyzed. It might have a location, time range, severity, category, related entities, cited URLs, and confidence score.

The key idea is provenance.

Y2 does not want downstream systems to see an extracted event and forget where it came from. Every derived event needs a trace back to the source report, profile, model pass, extraction prompt version, cited URLs, timestamp, confidence, and supporting context.

That provenance lets the rest of the platform ask better questions:

• Is this a primary observation or a derived one?
• Which report produced it?
• Which sources supported it?
• Which entities were linked to it?
• Did another source later corroborate it?
• Should it appear on a map, in an API response, or in a future briefing?

This is the core of the Y2 event layer: not just extracting events, but keeping the chain of custody attached.

Ontology Enrichment

Reports are useful on their own, but Y2 becomes more valuable when reports feed a shared ontology.

The ontology layer turns report evidence into durable graph objects:

• Entities: companies, countries, people, products, facilities, assets, software, threat actors, vessels, aircraft, and other named things.
• Places: countries, cities, regions, facilities, and coordinates.
• Incidents: events or situations with time, severity, category, and evidence.
• Relationships: edges that connect entities, places, incidents, and evidence.

This enrichment runs separately from delivery. That is intentional. A user should receive the report quickly, while the graph can continue processing in the background.

The enrichment path extracts candidate nodes, edges, incidents, and citations from report evidence. Then it resolves them against canonical records, dedupes where possible, writes evidence references, and updates the graph.

This is where Y2 moves from "a report was written" to "the knowledge base got smarter."

Fusion: Connecting the New With the Known

Fusion is the process of deciding how new extracted knowledge fits into what Y2 already knows.

If a report mentions a known company, vendor, CVE, port, region, aircraft, vessel, model, market, or incident, Y2 should not create a disconnected copy. It should resolve the thing to an existing canonical entity when possible, attach new evidence, and update the relationship graph.

Good fusion makes future analysis better. It lets later workflows retrieve existing context, avoid duplicate entities, identify repeated patterns, and surface corroboration. It also makes the product feel less like a feed and more like a living intelligence system.

The long-term goal is simple:

Every report should improve the next report.

Where Signals Fit

Signals sit between narrative and ontology.

A report says, "Here is what happened and why it matters." A signal says, "Here is the possible action, decision, or risk implied by that evidence."

Signals can be attached to reports, observations, incidents, places, and entities. They are useful because they keep the action layer structured. Instead of burying "monitor this supplier" or "patch this exposure" in prose, the engine can represent that recommendation as a typed object with provenance.

That makes signals available to dashboards, alerting, API consumers, future research, and human review.

The Internal Mental Model

Internally, the architecture is easiest to reason about as four loops:

1. The research loop gathers evidence.
2. The synthesis loop turns evidence into a human-readable brief.
3. The extraction loop turns the brief back into structured observations and signals.
4. The ontology loop resolves, enriches, and fuses durable knowledge.

Each loop produces a different kind of artifact. Each artifact carries provenance. Each artifact can feed the next run.

That is the real architecture.

What We Intentionally Avoid

Y2 should not treat model output as truth just because it is structured.

The engine is built around derived confidence, citations, provenance tiers, canonical resolution, and retryable background enrichment because those guardrails are what make AI-generated intelligence useful in practice.

We also avoid making every secondary step block the user-facing report. The system should deliver timely intelligence first, then enrich the graph behind the scenes.

Finally, we avoid unbounded recursion. Intelligence work needs curiosity, but production systems need budgets. RLM gives Y2 a controlled way to go deeper without turning every scheduled run into an open-ended research project.

The Bottom Line

Y2 works because it treats intelligence as a pipeline, not a prompt.

The report is only one artifact. Around it are the source trail, research findings, signals, events, evidence records, ontology objects, and graph relationships that make the next workflow smarter.

That is the direction of the platform: from automated reports to a living, provenance-aware intelligence graph.