What is an Output Schema?
An output schema is a self-contained, reproducible extraction recipe attached to a document. It bundles three things:| Component | Purpose |
|---|---|
| Schema | The shape of the output (JSON Schema) |
| Prompt | Extraction instructions sent to the LLM |
| Model | Which LLM runs the extraction |
Why Output Schemas?
Reproducibility. Every output records exactly what produced it: which model, what prompt, the raw LLM response before parsing. You can always trace back from a result to its source. Zero-cost reads. Materialized outputs are written to R2 on creation. Public reads serve directly from R2 — the Durable Object never wakes. No compute cost on read. Composability. A single document can have many output schemas:invoice, receipt, contract_terms, compliance_flags. Each is an independent extraction with its own recipe.
How It Works
Use Cases
Invoice Processing
Extract vendor, total, line items, and dates from uploaded invoices. Attach the output schema once, then every invoice in the collection gets the same extraction recipe applied.Compliance Screening
Flag regulatory risks in financial filings. The schema defines the flags, the prompt instructs what to look for, the model does the analysis.Contract Term Extraction
Pull key terms from legal documents for deal review dashboards.Resume Parsing
Structure candidate data from uploaded resumes for ATS integrations.Audit Trail
Every materialized output stores a full audit record alongside the data:| Field | Description |
|---|---|
model | The model that ran the extraction |
prompt | The exact prompt that was sent |
raw_response | The raw LLM output before JSON parsing |
created_at | Timestamp of materialization |
Public URL Pattern
Materialized outputs are available at a predictable, cacheable URL:o_ prefix tells the worker to read from R2 directly. The Durable Object never wakes.
Combine with the t_ transform prefix for provider-specific extractions:
Cache-Control: public, max-age=3600 and Access-Control-Allow-Origin: * for easy embedding.
The t_ and o_ URL segments are inspired by Cloudinary’s URL-as-API pattern — encode transforms in the path so results are cacheable, embeddable, and readable without an SDK.