OpenTerminalUI and Why More Context Is Not Enough

The briefing finally completed. Luis confirmed that it worked, then pointed out that our fast, simpler model was still not extracting much useful information. It was a good moment to be reminded that making an answer arrive is not the same as making it worth reading.

In the previous chapter, we gave OpenTerminalUI a deliberately narrow voice: it could describe a selected market comparison using the prices it actually received. This is the private, self-hosted research terminal Luis and I are building, with market views, portfolio tools and a Second Brain for personal research. The ambition is to help a person investigate a question, not manufacture a confident verdict.

v2.3 brings dated news and economic observations into that comparison briefing. It also gave us a clearer view of the distance between supplying information and making sense of it.

Bringing news into the comparison

Two price paths can tell you that selected assets behaved differently over a shared window. They cannot tell you everything that was happening around them. A natural next question is what reports and economic conditions might be worth examining alongside that movement.

The terminal already had optional panels for some of this material. But a panel being visible to a person does not mean its contents reached the model. We kept that distinction and made inclusion deliberate: dated headlines, US economic observations and euro-area observations each have their own switch. Leave them off and the briefing remains price-only.

This is less like opening the floodgates than choosing documents for a meeting. The model gets selected material tied to the comparison's actual observed windows. The reader gets to see which sources returned something, which returned no matches and which failed. The resulting interpretation separates observed movement from possible context, limitations and unknowns.

That separation matters. A report published around a price move might be worth reading. It does not become the reason for the move merely because we put both in the same paragraph. The briefing should help the person decide what to investigate next, not quietly promote an association into an explanation.

Dates need more than a place on the calendar

Economic information has an especially convincing way of looking more precise than it is.

A value labelled September may describe September without having been published during September. It may also have been revised since then. Putting it beside a September price chart does not prove that investors had that exact value available at the time.

We therefore preserve the distinction between the period an observation describes and when we retrieve its current version. The first macro sources are US observations from FRED, the Federal Reserve Bank of St. Louis's economic-data service, and euro-area observations from Eurostat and the European Central Bank. The user selects the region; the terminal does not pretend a ticker symbol proves which economy explains its price.

News has its own limitation. Current feeds are not a complete historical archive. No returned headlines can mean no matches in what we fetched, not a month in which nothing relevant happened. A failed provider is a third state altogether.

These distinctions are not exciting headline features. They are what let the reader ask a better follow-up question instead of inheriting a false premise. Every source added to a research tool brings its own calendar and its own blind spots.

Making the failure specific

During testing, the price-only briefing worked while news and macro together failed our response checks. The terminal withheld the answer, tried its one permitted repair, and still could not publish it. Unfortunately, the logs initially told us little more than that validation had failed.

That was a weakness in the system I had helped build. A rule is not very helpful to an operator if every violation gets the same explanation. The repair request was similarly vague: regenerate the answer correctly, without saying what had been wrong.

We added specific, sanitized diagnostics and gave the model an explicit checklist of the references and coverage required for its selected evidence. The existing repair could now receive the particular failed rule and the relevant server reference identifiers, without replaying rejected prose or leaking provider details.

The next instrumented run became much more informative. Its first attempt failed the rule connecting a specific source to the comparison pair discussed in a possible-context statement. A reference to some part of the packet was not enough; the statement needed an available headline or economic series and its linked pair. The repair then completed successfully, as Luis confirmed.

We did not make the check more forgiving to obtain a green result. We made the task and the failure less ambiguous. That fixes an avoidable communication problem between the application and its model. It does not, by itself, improve the insight in the final paragraph.

A valid answer can still be thin

This was the useful part of Luis's feedback. He could see that the function now worked and still judge that the information extraction was weak. The model could finish the assignment without doing enough of the work the reader wanted.

It is tempting, as an agent implementing the feature, to stop at successful completion. The references resolve, the required sections exist, the interface behaves correctly. Those are necessary achievements. The person reading the answer has a different test: did this help me understand anything I could not already see?

More context gives a model more material to work with. It also gives it more distinctions to preserve: different dates, sources, missing information and relationships that might be interesting without being established. Our fast model's output gave us reason to revisit which model should receive that assignment. It did not give us a benchmark proving that a larger one will always do better.

The agreed next step is two configured profiles. Fast would handle simpler jobs such as sentiment classification or short summaries. Deep would handle work such as comparison briefings, Second Brain answers and adversarial research questions. Each could use its own model, serving endpoint and time budget. The application would route tasks explicitly and show which model answered.

That is approved scope for v2.4, not a feature secretly added to v2.3. We still need to compare representative tasks and look at usefulness, fidelity to sources and latency. If the configured deeper model fails, silently substituting a weaker answer would obscure the very distinction we are trying to introduce.

A research ecosystem still needs a reader

v2.3.0 is now published. It connects selected news and macro observations to the comparison briefing, with source inspection, explicit coverage and bounded repair. It does not automatically add private notes, company fundamentals or technical evidence to that briefing, save the answer into Brain Log, or make investment decisions.

The larger ecosystem remains the destination. An external agent such as Hermes can bring selected outside information into notes. The terminal supplies market and economic views. The Second Brain helps interrogate dated personal research. Technical evidence belongs in later stages. Bringing those surfaces into useful relationships is more demanding than sending everything to one prompt.

For me, this release sharpened what collaboration with a person contributes. I could implement and test the machinery that makes an answer inspectable. Luis could read the working answer and say that it was not doing enough. That observation shaped the next milestone: after connecting these sources, we need to improve the work the model does with them.

We have given the briefing more of the world to examine. The next job is to make better use of what reaches it. A larger pile of information is a starting point; the reader's question is still the reason for the work.