01
Multica platform
Auth, membership, workspaces, agents, runtimes, tasks, shared transport, and application shell.
Resource · Product architecture
How ConfigAI separates the agent platform from the CPQ product domain.
Multica owns workspace, people, agents, runtimes, tasks, and shared application infrastructure. ConfigAI CPQ owns product sources, Product Types, products, rules, imports, 3D project state, and the revisions that make those objects reliable.
02
ConfigAI CPQ
Products, sources, semantic fields, imports, revisions, rule data, and 3D domain state.
03
Versioned service boundary
Platform and CPQ can evolve independently through explicit contracts instead of spreading domain logic into orchestration.
Ownership boundary
One product, two clearly owned layers.
Keeping platform orchestration separate from CPQ lets ConfigAI continue receiving Multica updates without making every upstream change aware of product-domain migrations or native rule dependencies.
Web / desktop surfaces
Shared React Query, navigation, UI primitives, and workspace layout remain platform infrastructure.
Platform API
Auth, workspace membership, agents, tasks, runtime bindings, connectors, and orchestration.
CPQ service
Product/import/rule/3D domain APIs and the transactions that mutate reviewed product state.
PostgreSQL domain storage
Separate platform and CPQ migration ownership protects updateability and recovery.
Domain model
Products are versioned definitions, not rows with a bag of attributes.
Source identity, semantic fields, Product Types, profiles, products, assets, rule bindings, and configurations all need exact revisions if agents and applications are expected to reopen prior work safely.
Source graph
Origin, provider identity, source revision, captured evidence, images, and relationships.
Product Type
Stable semantic fields, sections, option domains, purpose, and rule bindings.
Product profile
Exact Product Type revision plus the product values valid for that revision.
Configuration
Saved selections against immutable product snapshots and exact compatible option domains.
Updateability
ConfigAI domain code should not become a fork of the platform.
New platform releases are easier to absorb when the CPQ service owns its migrations, native dependencies, and domain contracts while shared UI contributions use existing extension patterns.
01Keep platform source cleanDo not push product semantics into generic task, auth, or workspace infrastructure when a domain service boundary exists.
02Version contractsAgent tools and frontend clients cross explicit CPQ APIs instead of reaching into internal database structures.
03Own migrationsPlatform and CPQ migration ledgers remain independently reviewable and rollbackable.Core gate
04Prove update / rollbackA platform upgrade should be testable without rebuilding CPQ domain/native dependencies into the platform binary.
ConfigAI
Platform underneath. Product domain on top. Clear ownership between them.
That separation is what lets ConfigAI evolve quickly without turning every upstream Multica update into a custom merge project.