spb/wp13_uqo

1% ============================================================================2\section{Execution Substrate and Document Generation}3\label{sec:capabilities}4% ============================================================================56Having described how the agent is orchestrated, we now detail the two subsystems that turn its7plans into artifacts: the sandboxed Python substrate that executes arbitrary model-authored code,8and the pipeline that renders the resulting report into multiple document formats. Both are9described at the mechanism level.1011\subsection{The Python execution sandbox}12\label{subsec:sandbox}1314When the model invokes the custom-analysis tool, the server does not evaluate the code in15process. It spawns a separate Python interpreter (resolved to a project virtual environment) as16a child process and communicates with it over standard streams, an isolation boundary that17protects the server from faults in the executed code and bounds its blast radius18(Figure~\ref{fig:sandbox}).1920\input{figures/sandbox}2122\paragraph{Inter-process protocol.} The server serializes a single JSON object---the23model-authored code, an optional context dictionary, and the market-data credential---and writes24it to the child's standard input, then closes the stream. The child reads the entire input,25executes, and writes exactly one JSON object to standard output: a success flag, captured26textual output, a list of base64-encoded figures, a list of generated files, and any error. The27child is launched with output buffering disabled so that nothing is lost, and with a hard2890-second wall-clock timeout. The parent collects standard output and standard error separately;29a non-zero exit code, or error output with no standard output, is treated as failure and the30error is surfaced to the model so that it can revise its code on the next turn. This single31request / single response discipline keeps the boundary simple and makes failures explicit.3233\paragraph{Namespace construction.} Inside the child, execution is performed by building an34\emph{execution namespace}---a dictionary---and calling the interpreter's \texttt{exec} against35it. Into this namespace the runtime injects the scientific libraries (NumPy, pandas, matplotlib,36and the broader set of seventeen), the two artifact helpers (\texttt{save\_excel},37\texttt{save\_word}), and a market-data client constructed from the supplied credential; any38context variables passed by the model are merged in last, so that the model can parameterize a39reusable script without string interpolation. Matplotlib is configured for a non-interactive40backend before any plotting occurs, so that figure rendering requires no display. As a41convenience, if the executed code defines a callable named \texttt{main}, the runtime invokes it42after execution and captures its return value.4344\paragraph{Output and figure capture.} Standard output and standard error produced by the code45are redirected into in-memory string buffers for the duration of execution, so that the model's46\texttt{print} statements become the textual result rather than corrupting the JSON protocol.47Figures are captured \emph{after} execution by a deterministic sweep: the runtime enumerates all48live matplotlib figure numbers, and for each, renders the figure to an in-memory buffer as a49PNG at fixed resolution with tight bounding boxes, then base64-encodes the bytes. This is exactly50why the single-call paradigm of Section~\ref{subsec:onecall} asks the model to emit each chart as51a \emph{separate} figure: the capture sweep turns each one into an individually addressable image52that the report can caption and reference. The encoded figures travel back through the JSON53response, are written to a served directory by the server, and are streamed to the client as54figure events.5556\subsection{Embedded numerical tools}57\label{subsec:numerical}5859Alongside the open-ended sandbox, the platform exposes a small set of pre-built numerical tools60for common tasks, so that routine requests need not regenerate code: a Monte Carlo path simulator61under a standard log-normal price model, a closed-form European option pricer that returns prices62together with the full set of risk sensitivities, a GARCH(1,1) conditional-volatility estimator,63and a Value-at-Risk calculator offering historical, parametric, and simulation-based variants64with companion risk ratios. These tools are conventional in quantitative finance and we do not65elaborate their formulae here; what matters for the architecture is that they share the sandbox's66contract---deterministic computation over live data, returning structured results and figures67through the same channels---so the model can mix them freely with custom code inside a single68analysis. Their detailed inputs and outputs are summarized in Appendix~\ref{app:numerical}.6970\subsection{The document-generation pipeline}71\label{subsec:docs}7273VQuant treats the deliverable as a first-class artifact. From a single Markdown report---the text74the agent streams to the user, with embedded figure references---the platform produces several75output formats, each through a distinct mechanism (Figure~\ref{fig:docpipeline}).7677\input{figures/docpipeline}7879\paragraph{PDF via headless rendering.} The challenge in rendering Markdown that contains80mathematics is that a Markdown parser will mangle mathematical syntax. The pipeline solves this81with a \emph{protect--parse--restore} mechanism: before parsing, every block- and inline-math82span is extracted and replaced by a unique placeholder token; the now math-free Markdown is83parsed to HTML; the placeholders are then restored as spans destined for a client-side math84renderer. The assembled HTML is loaded into a headless browser, which executes the math renderer;85the server explicitly \emph{waits for the rendered output to appear} in the DOM before capturing86the page to PDF with page furniture (headers, footers, pagination). Rendering in a real browser87engine is what lets complex notation and styled tables reproduce faithfully.8889\paragraph{Slides via model restructuring and two-pass \LaTeX.} Presentation output is a90two-phase mechanism. First, the platform issues a \emph{second} model call whose sole task is to91restructure the report into slide content---one idea per slide, special characters escaped, key92quantities emphasized---returning only body \LaTeX{}, not a full document. The server then wraps93that body in a fixed, branded Beamer preamble and compiles it with two sequential passes of the94\LaTeX{} engine, the second pass being required for cross-references and the table of contents to95resolve. When the analysis produced figures, the server additionally synthesizes one slide per96figure, integrating the visual output into the deck without further model involvement.9798\paragraph{Word via document conversion.} For an editable office format, the same Markdown is99handed to a document converter that emits a word-processor file, preserving tables, lists, and100heading structure.101102\paragraph{Spreadsheets with live formulas.} Within the sandbox, the spreadsheet helper writes103multi-sheet workbooks containing \emph{live} formulas---sums, ratios, conditional formats, data104bars---rather than pre-computed constants, so the recipient can audit and modify the calculations.105This mirrors, at the spreadsheet level, the platform's broader commitment to auditable output:106the deliverable carries its own derivation.107108\paragraph{Sharing and persistence.} Finally, any report can be published to a stable, unique URL;109the server stores the report content and its figure references and serves them through a public110viewer, so an analysis can be revisited or cited without re-running the computation. Sessions,111token ledgers, and cost estimates are persisted per user, supporting both continuity and the112operational analytics discussed next.113