The packages/csg-schema Zod definitions are the canonical source, and the TypeScript types are inferred from those same objects. A CI gate holds the Zod source to the Product Gating Spec field by field. Other language bindings are on the roadmap, not shipped — the table below says which is which.
Take field77 (the §3 Master Router). The enum is declared once in Zod; the type is inferred from it; the CI manifest pins it to the spec.
export const MASTER_ROUTER_CHOICES = [
'working_capital',
'ar_financing',
'po_financing',
'inventory_financing',
'real_estate_financing',
'equipment_financing',
'letter_of_credit',
'stretch_financing',
'other',
'exploring_options',
'unknown',
] as const;
export const MasterRouterSchema = z.object({
field77: MasterRouterChoiceSchema,
});export type MasterRouterChoice =
z.infer<typeof MasterRouterChoiceSchema>;
routeFromMasterRouter('ar_financing');
// {
// branch: 'Factoring',
// sections: ['§6'],
// needs_consultation: false,
// }{
id: 77,
section: '§3',
name: 'master_router',
status: 'implemented',
}main-pipeline.yml runs the csg-schema suite as part of the Vitest workspace, and that suite includes a parity test asserting that every field in the spec manifest — 90 entries today, transcribed from the Product Gating Spec — has a matching key in an implemented FIELD_IDS_constant. Mark a manifest field implemented without shipping its Zod definition and the build fails.
Zod and TypeScript are the two forms that exist and stay in lockstep by construction. The OpenAPI components are real but hand-written. JSON Schema, Python, and Go are roadmap.
packages/csg-schema/src/sectionsThe canonical source. parse / safeParse plus superRefine cross-field rules — FEIN required only for US registration, state vs province lists swapped by country.
@capitalsource/csg-schemaEvery exported type is a z.infer of the object above it, so there is one definition rather than a type and a validator that can disagree. No `any` anywhere.
docs/openapi/v1.yamlReal and linted by redocly in CI, but hand-maintained — not emitted from the Zod source. Treat mismatches as bugs and tell us.
not generated yetThere is no JSON Schema emitter on the Zod source today, and no schemas/csg-1003.json to download. Language-agnostic consumers use the OpenAPI components for now.
capitalsource-csg-schema (unpublished)V2.1 target. Pydantic v2 + dataclass twin generation. Not on PyPI.
csg-schema-go (unpublished)V2.1 target. Struct tags plus a branch-dispatch helper. No public module yet.
Every field has a canonical slug and a spec field id that never changes. §2 core is required on every submission; §4 cross-cutting blocks are required when the product branch selected by Field 77 pulls them in; each branch adds its own fields.
§7 PO Financing (7), §8 Inventory (6), §10 Equipment (7), §11 Letter of Credit (7), and §12 Stretch (2) round out the 90. Source of record: packages/csg-schema/src/sections/ and the Product Gating Spec. There is no generated per-field reference site yet.
Known gap: the spec's un-gated financial block — employee counts, sales model, average monthly revenue, amount needed, use of funds — is written in §2 but has no Zod definition yet, so it is not in the 90 and not in the parity manifest.
@capitalsource/csg-schema ships the Zod validators and their inferred TypeScript types. The MCP server, REST API, and Recurser CLI all consume it — nobody redefines a field. It is workspace-internal at v0.0.1 and not published to npm, so today you consume it through the API, the CLI, or a copy of the spec we send you.