Foundry
Every document a deliverable, not a draft.
Every proposal starts as a blank page and ends as a manual cleanup job
A word processor hands you a blank canvas; a chat box hands you a first draft that still contradicts itself in section six and needs an hour of formatting to match your brand. Either way, the work the tool was supposed to do lands back on you. Foundry turns the document into a structured, composable asset: you declare what a document type should contain, generate it through a pipeline that knows the difference between drafting, checking, and validating, then collaborate, version, export, and sign without leaving the platform. Documents are structured assets, not opaque blobs.
How it differs
Word processors are blank canvases. Foundry starts with structure: pick a document type (SOW, proposal, contract, NDA) and the platform outlines the sections and fills them based on context and tone. Version control, collaboration threading, and multi-format export are built in.
E-signature tools handle templates and signing. Foundry inverts the order: generate the content first through a real pipeline; add signature fields after. Foundry is the composition layer; e-signature is one phase of a longer lifecycle.
A chat session produces a first draft. Foundry produces a deliverable. Five passes, each with a distinct job. The same input today produces the same shape of output tomorrow, with every step audit-logged and re-runnable.
Who it’s for
Contract managers generating SOWs, amendments, and change orders from templates with variable data pre-filled, reviewing for consistency, and tracking approvals.
Sales engineers spinning up proposals quickly, customizing in real time, and exporting branded PDFs without opening a word processor.
Legal ops defining document types with required fields, validating against schemas, and storing standard language as reusable patterns.
Content authors building long-form pieces in the rich editor, using the strengthen pipeline to improve tone, and exporting to PDF, HTML, DOCX, or Markdown as the channel requires.
What it does
Five passes, each independently testable. Pass one builds the structure from the schema. Pass two generates the content for each section, with the right intelligence operation assigned to each element type. Pass three runs a cohesion check across sections, catching the proposal that introduces a price in section two and contradicts it in section six. Pass four runs a compliance check against the document type’s validation rules. Pass five writes a summary the reviewer reads before approving. Each pass can be re-run with a different provider from the Prompt Manager without re-running the others.
Nine element types. Rich text, checklists, tables, callouts, numbered steps, image grids, dividers, file attachments, and changelogs. Each has a JSON schema, gets validated on save, and supports its own set of intelligence operations. The restrictions are not annoyances; they are the reason a Foundry document compiles cleanly to a branded PDF without manual cleanup.
Brand kits inherited automatically. A document bound to an Orbit company exports with that company’s logo, colors, fonts, and templates already applied. The signer is pre-filled from the company’s default signer record.
Every operation captured by the AIAuditLog. Provider, model, prompt, response, cost, user, isolation boundary. When a customer or regulator asks how a section was produced, the answer is in the log.
How it fits the ecosystem
Foundry sits downstream of Orbit and Forge, upstream of the Client Portal and Aria. An Orbit deal triggers a Foundry SOW generation. A Forge dossier or legal matter feeds source material as an input template. The completed document publishes to the Client Portal, signed by the customer in their own brand. The signed PDF can be voiced by Aria as an onboarding briefing. When an OS knowledge byte changes, Foundry surfaces a “source updated, regenerate?” affordance on every document that referenced it.
[Request Early Access]