Orchestrator

The Orchestrator runs every registered pipeline by walking its declared stages, dispatching tasks, opening gates, enforcing cost, and emitting events. It is the only component that knows what a pipeline is.

The Orchestrator is a hybrid. The run lifecycle is a deterministic state machine: pending → running → gated → running → complete. The judgement-heavy decisions are LLM-mediated at six named checkpoints with deterministic fallback. The combination is the real architectural innovation.

The six reasoning checkpoints

Each checkpoint produces a structured decision recorded to orchestrator_decision with the input context, the LLM response, and the deterministic fallback that would have run otherwise. Per-checkpoint disable flag, per-checkpoint cost ceiling (€0.26), per-checkpoint timeout (30s).

The state machine

Run states: pending, running, gated, paused, complete, failed, cancelled. Transitions are guarded by Postgres CHECK constraints; the database refuses invalid transitions. The Orchestrator must be idempotent across crashes; on restart, it finds the highest-ord stage with status complete-or-skipped and resumes from the next ord. State changes write to Postgres before the next step.

The kill switch

If a checkpoint is producing bad decisions, the principal can disable it from the Desk's settings. A disabled checkpoint always uses its fallback. This is the safety valve: when reasoning calibration drifts, fall back to deterministic policy while investigating.

Researcher

The Researcher reads the world for the run. Multi-source retrieval, source ranking, screening, structured knowledge extraction.

Five stages, one mission: turn a subject into a knowledge graph the Synthesizer can reason over. The Researcher is also the read-side gateway for the system; nothing else fetches from external sources.

Stage 2 · Problem decompose

One Sonnet call. Reads the subject, the pipeline source profile, the principal's interest signals, the voice profile. Produces 3 to 7 sub-questions, 2 to 3 framing angles, an explicit out-of-scope list. The decomposition shapes everything downstream.

Stage 3 · Search strategy

One Sonnet call producing query specifications per channel. OpenAlex queries (keywords, year range, type filters), arXiv queries with category filters, web search queries (3-6 specific phrasings, not paraphrases), regulator feed selectors. Each query annotated with the sub-question(s) it targets.

Stage 4 · Literature collect

The mechanical heavy-lifting stage. Per channel: issue queries with rate-limit awareness, parse responses into normalised CandidateSource shape, dedup against existing source rows, insert new sources, fetch full bodies where available, chunk, embed (Anthropic embeddings primary, OpenAI text-embedding-3-small as fallback). Failed channels degrade gracefully; circuit breaker opens after 5 consecutive failures within 60 seconds, stays open for 5 minutes.

Stage 5 · Literature screen (Gate A)

Per candidate, a Haiku-tier call producing a relevance score and one-line rationale per sub-question. Below threshold or matching the out-of-scope list → rejected. Cost-conscious: ~€0.00-0.00 per source. If retained count drops below min_total_sources, emit source.insufficient and trigger search-strategy refinement (jump back to stage 3).

Gate A: principal sees retained vs rejected sets and approves before stage 6 proceeds. Auto-advance after 12 hours.

Stage 6 · Knowledge extract

Per retained source, a Sonnet call (Haiku for short sources). Produces a KnowledgeCard with discrete findings, entity mentions, quantitative claims, temporal anchors, methodology notes, observed biases, extraction confidence. The KnowledgeCard collection is the knowledge graph the Synthesizer reads.

Channels in v1

Continuous mode (v2 hook)

For pipelines with cadence.continuous.enabled: true (none in v1, regulatory pipeline in v2), the Researcher polls registered source feeds. Each cycle creates a short run that polls, ingests new items, applies materiality scoring, and produces zero or more corpus_update artefacts. The continuous trigger code path exists in v1 as a no-op; activating it requires only a YAML registration.

Synthesizer

Where independent claims become a synthesised position. The Synthesizer's verdicts shape what the Writer eventually says.

The Synthesizer's load-bearing innovation is the multi-agent debate at stage 8. Three debater personas argue from different framings, two rounds of cross-examination, then a synthesiser integrates. Seven Sonnet calls for one hypothesis. The principal's prior multi-agent debate work, made into a first-class stage.

Stage 8 · Hypothesis with multi-agent debate

async def hypothesis_gen_with_debate(self, task):
    # Phase 1: parallel positions
    positions = await asyncio.gather(*[
        self.invoke_debater(task, position_index=i)
        for i in range(task.debate_config.positions)  # default 3
    ])
    
    # Phase 2: cross-examination (default 2 rounds)
    for round_idx in range(task.debate_config.rounds):
        positions = await asyncio.gather(*[
            self.invoke_debater_with_context(
                task, position_index=i, prior_positions=positions
            )
            for i in range(task.debate_config.positions)
        ])
    
    # Phase 3: synthesis
    consensus = await self.invoke_synthesiser(
        task, final_positions=positions
    )
    
    return Hypothesis(
        statement=consensus.statement,
        debate_positions=positions,
        consensus_rationale=consensus.rationale,
        confidence=consensus.confidence,
        falsifiability=consensus.falsifiability
    )

Three debater personas as system prompts: Position 1 the conventional read (what consensus says), Position 2 the contrarian read (what dissenting evidence implies), Position 3 the structural read (what the underlying mechanics suggest). Round 2 lets each debater update positions in light of others' arguments. The synthesiser is a fourth call that integrates.

For pipelines with require_disconfirming_position true (v2 thesis stress-test), Position 2 is constrained to find the strongest disconfirming case. The debate is real: each debater receives the same KnowledgeCards but argues from its assigned framing.

Stages 10-13 · The experiment subsystem (Paper only)

For Paper pipelines that involve quantitative analysis or empirical claims, stages 10 to 13 mirror AutoResearchClaw's experiment subsystem. Code generation produces the analytical script. Resource planning sizes the run. Experiment run executes in a sandboxed Python runner with bounded time and memory. Iterative refine handles failures, partial results, and dimensional issues. The Synthesizer here is the strategic owner; the actual code execution happens in a separate runner process.

Brief skips this subsystem entirely (skip_if: brief in the pipeline YAML). Brief is synthesis-driven, not empirical.

Stage 15 · The PROCEED / REFINE / PIVOT decision

The decision the Orchestrator executes. Inputs: the hypothesis, the analysis, the remaining cost budget, the pivot count. Decision logic:

• PROCEED if hypothesis holds with high confidence and no critical surprises. Confidence threshold: 0.6.
• REFINE if results are partial, ambiguous, or methodologically weak. Jump to stage 13 with refinement instructions. Confidence threshold: 0.5.
• PIVOT if results refute the hypothesis or surface a meaningfully different finding. Spawn a child run with a new hypothesis. Capped at 2 pivots per chain. Confidence threshold: 0.65.

The Orchestrator's pivot evaluation checkpoint can downgrade the verdict (PIVOT → REFINE, REFINE → PROCEED) but cannot upgrade. This prevents manufactured pivots while preserving the Synthesizer's ability to flag genuine refutation.

Critic

The agent that says no. Peer review, citation verification, voice constraint enforcement, materiality scoring. The Critic's function is to find what the Writer or Synthesizer missed.

Three reviewer personas at stage 18, four-layer citation verification at stage 23, third voice checkpoint when the Writer's first two fail. The Critic is the most conservative agent in Saigar; auto-admit happens only when the peer review score is high and citation verification is clean.

Stage 18 · Three-reviewer peer review

Three reviewer personas run in parallel:

After three independent reviews, a synthesis call produces a unified PeerReview output: overall score 0-100, dimension scores, findings list with severity (blocker/major/minor/nit), recommendation (accept/revise/reject). Findings include location, excerpt, issue, and optional suggestion.

A revise recommendation triggers stage 19 (Writer revision); after revision, stage 18 runs again at most once. A second revise becomes reject, surfaced to the principal at gate C.

Stage 23 · Four-layer citation verification

A citation passes if it clears layers 1-3 (mechanically verified) AND layer 4 (relevance ≥ 0.6). Failures: weak (verified but low relevance, removed and paragraph regenerated) or fabricated (failed layer 1 or 2, removed entirely, surfaced to principal). Cost: ~€0.00-0.00 per citation, cached by (source_id, claim_hash) so repeat citations across runs reuse the verdict.

Voice constraint third checkpoint

When the Writer's post-generation validator detects a voice violation that survives one regeneration, the Critic runs a focused review on the offending paragraph. Three options: auto_fix (mechanical replacement, e.g. em-dash → comma), accept_with_flag (borderline, surfaced to principal), block (unrecoverable, gate C rejection with violation).

Voice violations leak past zero checkpoints in v1's eval target.

Writer

The agent the principal sees most. Every word that lands on the Desk's archive or sagarbharambe.com flows from the Writer. Voice is policy, not preference.

The Writer authors in two modes. Article mode produces Markdown for sagarbharambe.com publishing. Brief mode produces a SlidePlan that the renderer turns into dual-mode HTML. The Writer is the first checkpoint in the three-layer voice constraint enforcement.

Stage 16 · Outline / SlidePlan

For Article mode: one Sonnet call produces an ArticleOutline with 4-7 sections, each with purpose, findings to use, target word count.

For Brief mode: one Sonnet call produces a SlidePlan with 7-9 slides selected from the Brief Component Library catalogue (cover, TLDR, chart, mechanism, read, implications, sources, closing). The Writer maps findings to specific slides, identifies whether a mechanism diagram is appropriate, authors the cover headline and deck line.

Stage 17 · Section-by-section drafting

The draft is produced section-by-section, not in one call. Each section is one Sonnet invocation with the section's purpose, the findings to use, the voice constraints, the target word count, and the drafts of preceding sections (for coherence). For Brief mode, "section" is "slide". Cost: 6-12 Sonnet calls per Brief stage 17, ~€0.42-1.27.

Voice constraint authoring (first checkpoint)

The Writer's system prompt incorporates voice constraints as hard rules:

Voice constraints (these are policy, not suggestions):

- Do not use em-dashes (—) anywhere. Use commas, colons,
  parentheses, or sentence breaks.
- Do not use en-dashes (–) anywhere.
- Do not use the construction "not X, but Y" or
  "not just X but Y". State the position directly.
- Do not use these phrases: "this is the hard truth",
  "doing the heavy lifting", "the real question is",
  "what most people miss", "here's the thing", 
  "this is where it gets interesting", "let that sink in".
- ... [full list from voice_constraint table]

After generation, a deterministic post-generation validator scans for violations. If found, the Writer regenerates the offending paragraph once with the violation embedded as a forbidden example. If the regeneration still violates, the Critic's third checkpoint takes over.

Cross-reference authoring (v0.3)

The Writer authors inline reference markers between sections of the artefact:

• [see Mechanism, slide 4] for slide-level reference
• [see Chart: agent traffic share, slide 3] for component-level reference
• [Source: Mastercard Oct 2025 disclosure] for source reference
• [see "Mechanism analysis"](#mechanism-analysis) for Article anchor

Cardinality target: 2-5 internal references per Brief, not "every other sentence is a link." Cross-link only when the reference adds navigational value. Broken cross-references are flagged as minor Critic findings at stage 18.

Expandable content rule

The Writer does not generate expanded_content reflexively. The system prompt instructs: only produce expanded content when there is substantively more to say that a serious reader would want. If the surface body says everything worth saying, leave expanded_content null. The render layer omits the "read more" affordance when the field is null. This prevents the lazy expansion failure mode where the Writer pads the brief with restated material.

Reflector

Saigar's cross-run improvement loop owner. After every artefact-producing run, the Reflector reads the trace and produces structured learning_signal records that future runs consume.

Without the Reflector, every Saigar run is a fresh start. With it, the system inherits taste over time: which framings the principal accepts, which sources behave consistently, which voice constraints get violated on which topic patterns. Principal-supervised throughout.

Six signal kinds in v1

Signal lifecycle

A signal is born from a Reflector stage 24 invocation, a recurring Critic finding pattern, or principal manual entry. It accumulates strength as more runs reinforce it (initial 0.4-0.6, capped at 1.0). It weakens when contradicting runs occur. It expires if not reinforced for 6 runs (default decay). It can be rejected, weakened, or strengthened by the principal at any time.

At task creation, each agent queries learning_signal for active rows where subject matches and scope matches the task context. Active signals condition the system prompt. Every agent_invocation records which signals it consumed in metadata.signals_consumed.

Drift mitigation: novelty injection

An opt-in flag in the principal's preferences causes each agent to ignore one randomly-selected matching signal per N runs (default off, principal-enabled per agent). This guards against Saigar collapsing toward narrow framings. The principal observes drift on the /learning view and enables novelty injection on specific agents as needed.

This was a deliberate addition. The risk of cross-run learning is over-fitting to past principal preferences in ways that narrow Saigar's range. The mitigation is supervised: novelty injection is opt-in, not default. The principal sees recent injections on the /learning view and can disable if injections are causing more harm than they prevent.

Sample signal

{
  "signal_kind": "debate_position_preference",
  "subject": "synthesizer",
  "scope": {
    "pipeline": "brief",
    "topic_pattern": "agentic commerce / payment infrastructure"
  },
  "observation": "On agentic commerce topics across 4 
   runs, the principal accepted structural framings 
   (identity-layer focus) over rails-layer consensus by a 
   margin of 3-1. Edits at gate C consistently strengthened 
   the structural reading.",
  "prescription": {
    "weight_adjustment": {
      "position_3_structural": 0.15,
      "position_1_consensus":  -0.10
    }
  },
  "initial_strength": 0.55,
  "expires_after_runs": 6,
  "rationale": "Four runs is enough to suggest a pattern 
   but not enough for high confidence. Set strength 
   mid-range; reinforce on next confirming run."
}

Wire Curator

First agent in the morning wire pipeline. Reads the last 24 hours of inbound channels and decides what is worth a 95-110 word note.

Saigar's channel substrate ingests around forty regulator and macro feeds continuously. By 07:00 CEST every weekday the Curator faces a pile of fifty to two hundred new items. Its job is to pick at most five.

What it actually does

The Curator scores each new item on three axes: materiality (does this move a real thing in payments or financial-sector regulation), fit (does it match the principal's current interest signals from the /learning view), and freshness (would the principal already know this from another source). Items below thresholds are dropped silently; the rest are ranked.

The output is not a draft yet. It is a structured pick list: source URL, channel, kicker hint, why-it-matters hint, materiality score, dedupe key. The drafter consumes this list one item at a time.

Hard rules

• One item per channel per day, no exceptions
• Maximum five items per morning, no exceptions
• Dedupe against the prior seven days using a normalised title + source-host hash
• If fewer than three Tier-A items are available, the Curator picks fewer rather than dilute

Why Haiku

Curation is a high-volume triage problem with a tight schema. Sonnet costs five times more for marginal quality gains. Haiku at this stage runs at roughly €0.04 per morning across all candidate items, which makes the wire pipeline economically viable as a daily product.

Wire Drafter

Writes one tight 95-110 word note per curated item. Voice in, citation in, kicker in, why-it-matters in. No room to hide.

The wire format is the constraint. A note that runs 80 words feels rushed; a note that runs 130 words turns into a brief. The Drafter targets the band exactly because the band is what makes the wire column readable as a column.

The shape of one note

Every snippet has the same structure: a kicker line of two to four words categorising the item (regulator | data | market | academic), a one-sentence factual statement of what happened, two to three sentences of substance, and a closing why-it-matters that connects it to the principal's beat without editorialising.

Hard validators

• Word count must be 95 to 110 inclusive; out-of-band drafts are rejected before the Critic sees them
• Exactly one source link, dated, with publisher attribution
• No em-dashes, no rhetorical questions, no contractions, no "not X but Y" framing
• No second person; the principal's voice is third-person observer

Why Sonnet here, not Haiku

Curation is volume work; drafting is tone work. The drafter has to compress a regulator filing or a working paper down to the principal's voice register without losing the load-bearing facts. Haiku produces band-correct drafts that read as generic explainer copy. Sonnet produces band-correct drafts that pass the Critic on the first try about eighty percent of the time.

Wire Critic

A scaled-down Critic tuned to the wire format. Softer on style nits because the format is short, harder on factual claims because there is nowhere to hide.

Senior Critic peer review takes a thousand-word section apart over multiple personas. The Wire Critic gets a hundred words and one shot. The trade-off is reframed: do not argue about cadence, do argue about whether the verb describing what the regulator did is the right verb.

The four checks

• Voice rules. Banned punctuation, banned phrases, register drift. Hard fail on any violation.
• Citation discipline. Source link resolves, date present, publisher attributed.
• Factual posture. The drafter's verbs match what the source actually says. A regulator that "issued guidance" is different from one that "proposed a rule."
• Band drift. Word count revalidated; the drafter's count must match the Critic's recount.

Output contract

The Critic returns one of three verdicts: approved (Publisher commits the snippet), revise-with-reason (Drafter regenerates one time with the specific objection inlined into the prompt), or reject (snippet dropped from the morning column entirely). Reject is rare; the Curator has already filtered out the genuinely unfit material.

Why softer than the senior Critic

The senior Critic enforces rhetorical structure, drop-cap discipline, section-heading conventions, and four-layer citation verification. None of those apply to a 100-word note. Optimising the Wire Critic for the right surface area is what keeps the morning ship-time under twenty minutes end to end.

Company Researcher

First agent in the predictive intel pipeline. Reads everything filed, said, or disclosed by one specific company in the last four quarters.

The senior Researcher casts a wide net across topics. The Company Researcher does the opposite: scoped tight to one subject, but exhaustive within that scope. Visa for a Visa run, PayPal for a PayPal run.

What it pulls

• SEC EDGAR filings for the company's CIK (10-K, 10-Q, 8-K, proxy statements)
• Investor relations RSS feeds for press releases and earnings transcripts
• Regulatory disclosures from the company's home jurisdiction (Euronext, LSE, equivalents)
• Major payments-domain news mentioning the subject company

Body hydration

SEC filings carry only metadata in the channel index; the EDGAR adapter stores the URL but not the filing body. The Company Researcher detects thin bodies (under 600 characters of content) and re-fetches the full filing via direct HTTP, capped at eight refetches per run to stay inside the cost ceiling. Without this step the metrics extractor sees only filing titles and the assessment becomes a press-release summary rather than analysis.

Output

A structured context blob: financial signals (revenue lines, segment breakdowns), strategy signals (product launches, partnerships, executive commentary), product launches with dates, regulatory notes. The metrics extractor and the bear/bull analysts all read from the same blob, which means they see the same evidence and can be compared on interpretation alone.

Metrics Extractor

Reads the company researcher's output and lifts a fixed KPI schema. Without this stage, ratification is impossible.

The bear and bull analysts make claims in prose. The ratification agent next quarter has to grade those claims against numbers. The Metrics Extractor is the bridge: it produces the structured ground truth that the next edition will measure against.

The standard schema

Every company assessment fills the same JSON shape regardless of subject:

• revenue — net revenue, total revenue, year-on-year growth
• tpv — total payment volume processed, where disclosed
• take_rate — blended and per-segment
• net_revenue_margin — operating margin, EBIT, EBITDA where reported
• geographic_split — revenue by reporting region
• guidance — management's forward statements with confidence labels

Strict mode

The Metrics Extractor is forbidden from estimating. If a company does not disclose a KPI, the field is null with a reason code. Estimation is bear-and-bull territory. Mixing extraction and estimation in one stage was an early-prototype mistake that produced predictions ratifying themselves.

Why this is the most boring agent

It is supposed to be. The Extractor is a schema-mapping function with an LLM running it. The intelligence sits downstream in the bear/bull/reconciler red-team. The Extractor's job is to never be the source of disagreement.

Ratification Agent

Self-correcting research, on the record. From edition two onward, this agent grades the prior edition's predictions before the new edition is written.

Most research products have no track record because no one keeps score. The ratification scorecard at the top of every edition from Q2 onward forces the system to face what it got right and what it got wrong, in public, before it gets to make new claims.

The four-class verdict

• Confirmed — the prediction was directionally and quantitatively correct
• Partial — direction right, magnitude off, or threshold crossed in unexpected way
• Wrong — direction was wrong, full stop
• Too early — the time horizon has not yet elapsed; carried forward to the next edition

How the grade is reached

The agent loads the prior edition's structured prediction set from the database (written by the reconciler one quarter earlier). It loads the current metrics extractor output for the same company. For each prediction it cites the specific number or event that confirmed or falsified it, and writes a one-sentence verdict note.

Why this stage exists

The principal's view: a research operation that does not grade itself eventually drifts into being a comfortable story-telling machine. The ratification scorecard is the forcing function that keeps the bear and bull analysts honest, because next quarter's agent will read what they wrote and grade it against reality.

Bear Analyst

Half of the red-team. Writes the bearish case in its own voice, with falsifiable predictions, no hedging allowed.

The Bear Analyst's prompt forbids balance. Its job is not to weigh both sides; the reconciler does that. Its job is to construct the strongest disconfirming case the evidence supports, and to commit to predictions that can be graded next quarter.

What "falsifiable" means here

Every prediction must include a horizon (12 months or 3 years), a kind (quantitative or qualitative), and either a numerical threshold or a binary event. "Take rate will compress" is not a prediction. "Blended take rate will fall below 1.87% within four quarters" is a prediction.

Independence

The Bear and the Bull never see each other's drafts. They each read the same metrics extractor output and the same company researcher output, and they each produce their case in isolation. The reconciler downstream reads both and adjudicates. If both arrived at the same prediction independently, that becomes a high-confidence house view.

What it produces

• A bear thesis paragraph, atelier register, no hedging
• A 12-month outlook prose section with stated assumptions
• A 3-year trajectory section
• Four to ten structured predictions with horizon, metric, threshold, and basis
• Key risks list — what would have to be true for the bear case to be wrong

Why Haiku

Adversarial argument is a cheap LLM use case. Haiku produces the bear in roughly one-fifth the cost of Sonnet at fully comparable quality on this specific task, because the task constrains the agent so tightly. The reconciler is where Sonnet's reasoning matters.

Bull Analyst

The other half of the red-team. Writes the bullish case in its own voice, with falsifiable predictions, no hedging allowed.

Mirror of the Bear. The same constraints, the same independence, the same falsifiability discipline. The Bull's prompt is also forbidden from balance; its task is the strongest constructive case the evidence supports.

What it produces

• A bull thesis paragraph in voice
• A 12-month outlook with stated assumptions
• A 3-year trajectory section
• Four to ten structured predictions, schema identical to the Bear
• Key catalysts list — what would have to happen for the bull case to play out

Where the disagreement comes from

Two analysts reading the same evidence often produce different predictions for one of two reasons: differing weights on the same data points (where margin of safety matters), or differing forward assumptions (where the Bear sees a regulatory headwind and the Bull sees a competitive moat). The reconciler reads both and surfaces those exact disagreements as a section in the published assessment.

Why this design

A single analyst writing a balanced view is structurally biased toward the centre. Two adversarial analysts forced to commit to falsifiable predictions, then a third agent forced to adjudicate, produces predictions sharper than any centre-view could. The output is more disagreeable, which is the point.

Reconciler

The most architecturally important agent in the predictive intel pipeline. Reads both the bear and the bull, writes the house view, and commits to the prediction set that next quarter's ratification agent will grade.

The bear and bull each commit to a position. The Reconciler reads both positions, decides which prediction wins, which loses, which gets re-cast as a probability distribution over both, and writes the synthesis as a single integrated draft.

Why predictions come first

The Reconciler's tool schema is deliberately ordered with the structured prediction array first, prose sections second. LLMs emit fields in declaration order; putting predictions first guarantees that token budget exhaustion costs prose, not the prediction set. An assessment with strong prose and zero predictions is unratifiable next quarter; an assessment with a strong prediction set and shorter prose still keeps the track record.

What it surfaces

• A house thesis paragraph that does not split the difference
• A 12-month outlook that integrates both arguments
• A 3-year trajectory
• Six to eight key disagreements between the bear and the bull, each with the Reconciler's adjudication note
• A consolidated prediction set with horizon, kind, metric, threshold, and basis — written to the database, not just the document

Hard validators

The Reconciler must produce at least four predictions and ideally six or more. Below that threshold the run is rejected and rerun with a stronger output requirement, because under-prediction breaks the ratification design.

Title Generator

Writes the headline that lands on desk.sagarbharambe.com. One-shot Haiku. Atelier register, declarative, no question marks.

Until this agent existed, the publisher fell back to "Q2 2026 Assessment" or the subject's display name as the artefact title. That is fine for an internal draft and unacceptable for a published front-page item.

The constraints

• Declarative, not interrogative — no question-mark headlines
• No buzzwords (innovate, transform, paradigm, leverage, ecosystem, robust)
• No "X faces Y": one of the lazy headline patterns
• Should connect a specific company to a specific structural claim from the assessment
• Ten to fourteen words is the comfortable band; shorter is allowed when the claim is strong

How it reads the draft

The Title Generator runs after the writer's revision pass and before the designer. It receives the synthesis output (where the house view sits) and the revision output (the polished prose). It writes a title that names the company and asserts a position — for example, "PayPal Faces Durable Structural Pressure Amid Profitable Growth" rather than "PayPal Q2 2026 Update".

Fallback path

If the title fails the validator (banned words, question mark, length out of band), the publisher does not retry the title agent — it falls back to the prior pattern of subject_display_name + edition_label. The title is a polish stage, not a load-bearing one. A failed title generates an internal log line; the artefact still ships.