Market Book Connector

1 Choose a run

Open a result that is already saved. No model runs and nothing is written.

Example results

Commentary

Recent runs

Runs started from this page, newest first: time · outcome status · backend.

Open a run by ID

Finds any run saved under connector/runs/<run id>/, including runs started from the command line.

2 Evaluation result

No run selected yet. Open a saved result or evaluate your commentary to see a result here.

3 Context, input & files

No run selected yet.

Guide

Start here: what this app does

This app takes a piece of market commentary and checks it against the Market Book, a curated research catalogue of market states. Each state comes with the observable signs, failure patterns, and policy implications that the research associates with it. A builder model turns your text into structured observations. A search step finds the states that look most similar. An evaluator model then decides which of those states, if any, the observations actually support, and it cites the research records it relied on.

The result is research context for an analyst to review. It does not measure the market, verify your commentary, or tell you to trade. You can explore saved results without any setup; evaluating your own text requires a configured command-line model (see Models).

Explore vs. evaluate

Explore opens results that are already saved. No model runs, and nothing is written. Evaluate sends your commentary through the full pipeline using the models you choose, which can take several minutes and, with a cloud model, uses your model account. Loading an example into the text box does not run anything.

What to paste

Prose describing what you see in markets, for example a morning note, a paragraph from a research piece, or your own observations. It does not need a fixed format. Specific, observable statements (what is rising or falling, where, over what horizon) give the builder more to work with. Phrases that read as trading instructions will cause the run to be rejected.

Models, roles, and backend profiles

Two steps use a model: the builder reads your commentary, and the evaluator judges candidate states. Each uses a backend profile, a named command-line tool configuration defined in the backend profile file the dashboard was started with (by default connector/configs/backend_profiles.example.yaml). The model itself may run locally or in the cloud, depending on that tool. The two roles may use the same profile or different ones. This page sends your choice for each role explicitly, so the profiles shown are the ones that run. The time limit shown is each profile's per-step limit.

What “mock” means

mock does not call a model. It copies a bundled sample output, so the result is the same sample whatever you type. Use it to check that the app is installed correctly and to see what a result looks like.

What happens during a run

The steps run in this order: your text is saved and fingerprinted; the builder produces structured observations; they are checked for format and prohibited wording; a local search picks candidate states from the catalogue; the evaluator judges each candidate; its output is checked; and a context record is built. The page learns only when the whole run finishes. It checks every two seconds. Model steps can take minutes. You can leave the page; the run appears under Recent runs when it finishes. The dashboard cannot cancel a run.

Which run am I viewing? Saved runs and run IDs

The “Now viewing” bar names the run whose result is shown, where you opened it from, and which profile each role used. The commentary box in Evaluate is for new submissions; it is not the input of the run you are viewing. That input is under Submitted commentary. Every run is saved in connector/runs/<run id>/. Runs started from this page are listed under Recent runs. Runs started from the command line may not be listed, so open them with Open a run by ID. Copy link gives a URL that reopens the same run.

Match, no match, failed

Supported match found: the evaluator accepted one or more candidate states as supported by your observations.

No supported match found: the pipeline completed and the evaluator concluded that none of the candidates is supported. This is a legitimate answer, not an error. It happens either when the phenomenon is not in the catalogue or when it is, but for a different asset class. The rationale explains which.

Failed: the pipeline stopped before producing a checked evaluation. That is a software or validation outcome, not a judgment about your commentary.

Confidence and match strength

Support for this conclusion is the evaluator's overall rating of the evidence: well, partially, weakly, or un-supported. For a no-match, it rates the evidence for not matching. Match strength (strong, moderate, weak) rates a single matched state by how much of the evidence the state expects your observations actually supply. Neither is a probability or a forecast.

Reading a matched state

The card shows the catalogue state and which of your observations support it. It lists the evaluator's evidence caveats, meaning what it could not confirm. Then come the research records it cited, and known ways this reading can be wrong. Read the caveats before the citations.

Evidence citations

Each citation is a record from the Market Book catalogue: an observable signature, policy implication, failure pattern, or cited claim. The text is shown as stored in the catalogue. The pipeline checks that every cited record belongs to the candidate being matched; it does not check that the record fully proves the match.

Rejected candidates and reason labels

These states were sent to the evaluator and rejected. Labels:

different asset class / scope;
not enough evidence in the input;
surface-similar, different phenomenon;
opposite direction (your observations move the other way from what the state expects);
sibling state fits better.

“Why retrieval suggested it” shows the records that made the search step pick it.

Similar states not sent to the evaluator

The search step ranks every state by textual similarity and sends only a shortlist to the evaluator. These are the next-highest-ranked states just outside that shortlist. The evaluator never judged them. The score is a similarity measure used for ranking, not a probability and not a near-match.

Limits, caveats, and missing observations

Caveats are the evaluator's own statements of what the evidence does not establish. Declared missing observations lists only the specific observations the evaluator flagged as absent in a structured field. An empty list does not mean nothing is missing; gaps described in the caveats still apply. Constraints on use and Follow-up measurements listed are derived automatically from those declarations and from weak matches. Ways this reading could be wrong are failure modes attached to the matched states.

Posture labels

Each matched state gets one label from a fixed monitoring vocabulary. The labels are: defensive monitoring, risk-off monitoring, neutral observation, regime dependent, caution flagged, no actionable posture, and unsupported. When nothing matches, the posture is no actionable posture. These labels are context for an analyst, not a recommendation to act.

Pipeline checks

These checks show whether each pipeline step completed, and whether the three validators passed: builder output, evaluator output, and context record. They confirm structure, allowed wording, and valid references. They do not confirm that the interpretation is right.

How the builder read your commentary

This is the builder model's summary, asset scope, date/horizon, and numbered observations. Each observation has a dimension, a direction, a magnitude, and a statement. All of them are taken from your text; none is a fresh market measurement. The evaluator refers to observations by their number.

Files and downloads

Signal context (JSON/YAML) is a compact machine-readable summary of posture, caveats, constraints, and source-file paths. It is not a copy of this page, and some fields shown here, such as the observation summary, can be empty in it. It exists only when the run completed. All other files are saved under the run's folder. The input fingerprint identifies the exact text used; it does not vouch for it.

When a run fails

The explanation names the step that stopped and why. Output failed validation means a model produced output that broke the format or wording rules, and the pipeline refused to continue. The pipeline did not complete means a step errored, for example a CLI time-out or a missing configuration. Anything shown below the failure was produced before it and is marked Not validated. Technical details are available for troubleshooting.

What results do not mean

A result is not a market measurement or a forecast. It does not confirm that your commentary is true, and it is not a trading instruction. Passing checks means the output is well-formed, not that it is correct. An empty field means nothing was recorded there, not that nothing is missing.

1 Choose a run

2 Evaluation result ⓘ

3 Context, input & files

2 Evaluation result