Lesson 56.1 gave you the analysis card. Now we use it on the instructor's own project: Sonariq, also called Research Desk in this course — a source-linked research application for public companies. Read it as a system case, not investment guidance. Nothing here tells anyone what to buy or sell. It teaches how a pile of scattered public material becomes one organized brief a person can revisit.

The user and the job

The user is someone researching a public company — an investor, a student, an analyst, a curious builder — who needs to locate, organize, compare, and revisit source-backed information without rebuilding the same trail every time.

Name the pain concretely. Today that person opens ten tabs: a filing, two news articles, an earnings transcript, a data-provider page, a forum thread of uneven quality. They take scattered notes. A week later they remember the conclusion but not which source supported it, so they redo the work. The recurring job is not "get an answer about a ticker." It is "build a research trail I can trust, extend, and return to."

That distinction shapes everything. A question box optimizes for one fast answer. A research desk optimizes for accumulation: each session leaves the user with more organized evidence than they started with.

The workflow map

The application is a pipeline with memory. Follow material left to right:

public / provider data → source-aware processing → structured brief
  → private watchlist + saved context → refresh → evidence + logs

Public / provider data. Inputs are a company or ticker plus approved sources: filings, reputable news, provider data, transcripts. Source selection is a product decision, not a model setting — which providers are allowed determines what the brief can ever claim.

Source-aware processing. Models, Markdown instructions, JSON handoffs, and agents fit here, in that order of reliability. Markdown instructions set the brief structure; JSON handoffs carry extracted facts between steps without letting prose smuggle in new claims; agents handle bounded subtasks (fetch one filing section, extract one table) with limits and review. Model selection matters less than this plumbing: the same model with clean handoffs beats a stronger model with tangled ones.

Structured brief. The output is a consistent document — business summary, financials, risks, sources — where every material claim carries a visible link. Consistency is the feature: the tenth brief reads like the first, so comparison is possible.

Private watchlist and saved context. Saved tickers, notes, and preferences belong to the user alone. This is the state that compounds: the product remembers what the user follows so the next session starts ahead.

Refresh, evidence, and logs. Data goes stale, so refresh behavior is specified: what re-fetches automatically, what waits for the user, what marks itself outdated. Logs record what was fetched, when, from where — the audit trail behind the brief (recall Part XI on logs as a failure trail).

The trust boundary

This is the most important section of the case. A research application can organize and explain source information. It must do four things at the boundary:

1. Preserve sources. Every claim a user might act on traces to a retrievable source. No orphan facts. 2. Distinguish facts from assumptions. Retrieved numbers are facts with citations; model inferences, comparisons, and summaries are labeled as derived. The interface must show the difference, not bury it in uniform prose. 3. Never pretend to make financial decisions. The brief informs; the person decides. No autonomous trading, no buy/sell directives, no risk language that implies a recommendation. 4. Protect saved data. Watchlists, notes, and preferences are private user state. Ownership checks, authentication, and authorization from Part XI apply in full — "it is only an MVP" never excuses leaking one user's list to another.

When the system is wrong — a stale filing, a misread table, a provider outage — the design degrades honestly: show the source date, flag the conflict between two sources instead of silently picking one, and say what is missing. When it is unavailable, the saved brief and watchlist still read; only refresh pauses. Trust is what the product does on its bad days.

The wedge and the non-goals

The wedge is deliberately tiny: one company, one brief with visible sources, one saved watchlist item. A new user types a ticker, receives a structured brief, saves it privately, and returns to it later. That single loop exercises the whole pipeline — input, processing, brief, state, refresh — as a vertical slice (recall Class 54.4).

The non-goals are stated with equal care. Version one does not include portfolio tracking, social feeds, analyst marketplaces, price alerts, or autonomous trading. Each exclusion protects the wedge: portfolio tracking would demand position math and brokerage integrations; social features would demand moderation; trading would cross the trust boundary entirely. Saying no to those is what lets v1 ship as a learning instrument rather than a sprawling promise.

Transfer: the same shape in four new domains

The Research Desk pattern — approved sources, structured brief, private state, refresh, evidence — transfers anywhere someone re-researches the same kind of thing. Sketch one:

• Property. Sources: listings, registries, tax records, local news. Brief: one address, price history, ownership, risks. Private state: saved searches and viewing notes. Return loop: new listings and price changes on saved areas.
• Legal documents. Sources: filed documents, statutes, case databases. Brief: one matter, timeline, cited clauses, open questions. Private state: matter folders and annotations. Quality check: every extracted clause links to its page and paragraph.
• Public policy. Sources: bills, committee records, agency releases, reputable coverage. Brief: one proposal, provisions, supporters, critic timeline. Refresh: status changes and new amendments.
• Products. Sources: spec sheets, reviews, manuals, recall notices. Brief: one model, verified specs, common failure reports, open questions. Return loop: price drops and new reviews on saved items.

In each case, ask the card's questions fresh: who is the researcher, which sources are allowed, what structure makes briefs comparable, what private state compounds, what refresh keeps it alive, and where the trust boundary sits (a legal brief organizes; it does not give legal advice).

Exercise: map a different research workflow

Pick one domain above. Write a one-page research-product map: allowed sources, brief structure with citation rules, private state and ownership, refresh behavior, three quality checks, the return loop, and the trust boundary in one paragraph.

Done means: a research-product map that could be scoped into a real v1 — specific enough that someone could write V1-SCOPE.md from it next. Verify: every material claim in your sample brief traces to a named source type, and your non-goals list has at least three items. Common failure: a map that is really a feature wishlist ("AI chat, alerts, social sharing") with no source list and no boundary. Sources and boundaries are the product; everything else is decoration.

Check your understanding

• Why does the brief's consistent structure matter more than any single answer's fluency?
• Where do Markdown instructions, JSON handoffs, and agents each fit in the pipeline, and why that order?
• State the four-part trust boundary in your own words.

Sources and unknowns

• Research Desk / Sonariq running examples and v1 scope: Part XII outlines (course material, L1 for course claims). Product details described here reflect only the instructor's publicly shareable description as referenced in the Class 56 outline — reconfirm that description and its permissions immediately before publishing, and describe only what is public/shareable.
• Unknowns (explicit): live feature list and permissions beyond the outline description; data providers in use; refresh intervals; user metrics — none are stated here and none are needed for the mechanism lesson.

In the next lesson we turn to the opposite shape: Outbid.lol, where a tiny public mechanic — not a deep workflow — creates a loop people cannot resist watching.