Platform architecture

A manifest-driven vertical AI platform keeps products distinct without rebuilding the engine

How a shared AI product engine can support different brands, buyers, compliance postures, workflows, and content without turning each vertical into a fork.

A vertical AI platform has to preserve two truths at once. The products need different buyers, brands, workflows, data rules, and language. The company also needs shared mechanics for identity, model access, retrieval, billing, engagement, and operations.

Teams lose the platform advantage when they copy a successful application and let each copy drift. They lose market specificity when they force every product through one generic interface. A manifest-driven architecture creates a boundary between platform choices and product truth.

Put platform variation in a typed manifest

The manifest should describe choices that the shared engine can enforce. Useful fields include the product name and domain, task-to-model mapping, safety classifier, compliance posture, storage adapter, billing adapter, community adapter, and feature flags.

A typed schema matters because a configuration error can change data handling or safety behavior. Validation at boot gives the team one place to reject an invalid combination before the application serves traffic.

Keep buyer workflows inside the vertical

A lesson, roleplay persona, clinical assessment, quote workflow, interview drill, or Bogotá place guide belongs to the product. Moving this material into the shared engine makes the engine depend on one market's language and assumptions.

SVTech routes product pages through vertical-local modules. Those modules call shared packages behind a thin boundary. The route stays readable in the language of the product while the platform can evolve its implementation.

Promote shared code after reuse appears

Premature platform work creates abstractions without consumers. A stronger rule starts mechanics inside one vertical. The team promotes the code after a second vertical adopts the same behavior or a committed third use case proves the need for a manifest selector.

Decision rule: configuration belongs in the manifest, buyer-specific content stays in the vertical, and shared mechanics enter the engine after real reuse.

Use the platform to accelerate evidence

The architecture earns value when it shortens the path from buyer problem to working pilot. Shared identity, AI routing, retrieval, measurement, and operations remove repeated infrastructure work. The team can spend that time on the workflow, controls, content, and adoption path that determine whether the buyer pays.

Apply this to a real workflow.

Bring the buyer, current process, constraints, and success measure.