Proof Configuration
Keep Tessera Agent's Generative UI proof reproducible without inventing a public Studio config API.
This Generative UI proof does not depend on the separately published
@open-tessera/studio configuration facade, and there is no tessera-agent
component CLI. Its configuration is owned by explicit package contracts and
test fixtures rather than a second top-level product API.
Ownership
| Concern | Current source of truth |
|---|---|
| Protocol limits and wire schemas | packages/protocol |
| Component identity, schemas, and Catalog slices | packages/catalog and packages/components |
| Proposal normalization, validation, and commit | packages/compiler |
| Query resources, grants, and projections | packages/resources |
| Host authority, sessions, and trusted events | packages/server |
| Browser replay, resolved props, and commands | packages/client |
| React surface and exact renderer lookup | packages/react |
| Tessera data-agent renderers and recipes | packages/ui |
| Deterministic and model-evaluation acceptance | the proof specification and fixtures |
The Host must freeze the Component Contract slice, authority, resource grants, limits, locale, timezone, and renderer capability manifest for each Surface session. A model cannot configure or expand any of them.
Data-agent profile
The current product profile is deliberately fixed to six analytical Component
Contracts. Its one chart Contract, data.chart, contains 17 audited recipes.
The recipes form a strict discriminated union over the same Contract; they are
not extra protocol component types and cannot inject arbitrary presentation
values.
Query rows stay in the Resource Gateway. The model receives only bounded,
policy-approved descriptors and binding references. Renderer props are resolved
for one node after trusted events reach SurfaceController.
Local environment
No secret is needed for deterministic proof gates. OPENROUTER_API_KEY enables
only the optional documentation chat route. Database credentials and the
Tessera Agent product integration belongs to its Host surface and must remain
server-only there.
Any future public config facade must be implemented and tested before it is documented here. Until then, examples use concrete repository APIs and fixtures only.