ContractSpec docs

OSS-first docs

These docs teach the open system first: contracts, generated surfaces, runtimes, governance, and incremental adoption. Studio shows up as the operating layer on top, not as the source of truth.

AI index

Marketing & BillingOS-adjacent FormSpecs

Contract-first FormSpecs for form-like marketing/BillingOS UI; rendering goes through the design-system FormSpec renderer and submission binds to OperationSpecs.

field.key.label
Marketing & BillingOS-adjacent FormSpecs
field.version.label
field.type.label
field.title.label
Marketing & BillingOS-adjacent FormSpecs
field.description.label

Contract-first FormSpecs for form-like marketing/BillingOS UI; rendering goes through the design-system FormSpec renderer and submission binds to OperationSpecs.

field.tags.label
marketing,billing,forms,lead-capture,estimate
field.owners.label
field.stability.label
public

Three generic, reusable FormSpecs make form-like marketing/BillingOS UI contract-first. Each binds its action to an OperationSpec by `key`+`version`; hosts own copy, option catalogs, provider logic, and handlers.

•

`marketing.lead.capture.form` (`MarketingLeadCaptureFormSpec`) → action binds

to `marketing.lead.capture` (command).

•

`marketing.estimate.input.form` (`MarketingEstimateInputFormSpec`) → action

binds to `marketing.estimate.calculate` (query). Bundle options are illustrative defaults; hosts override them.

•

`billing.estimate.intake.form` (`BillingEstimateIntakeFormSpec`) → action binds

to `billing.estimate.prepare` (query, **side-effect-free**).

These specs are schema/layout/action metadata only. The design system renders fields and an operation/host-provided result; it never computes pricing, calls a provider, payment, CRM, or invoice path. Live billing execution stays host-owned.

Relationship to `marketing/forms.ts`: `MarketingStudioDemoRequestForm` + `marketingFormRegistry` are the Studio-specific demo-CTA form and its registry; the specs here are the generic, reusable lead/estimate/billing forms.