Multi-vertical isolation
The platform distinguishes top-level applications from product sub-verticals.
| Application | Sub-verticals |
|---|---|
rainty | file, rent, future rAInty modules |
rendicontazione | application-specific modules |
bandi | application-specific modules |
Every new processing run pins a platform context containing applicationCode, verticalKey, organizationId, userId and vectorProfile. Existing file runs remain readable and resolve to applicationCode=rainty and vectorProfile=rainty-default.
PostgreSQL
Authentication, sessions, applications and organization membership remain central. Domain data belongs to an application schema selected through backbone_platform.schema_bindings. Domain queries must use the selected schema explicitly and must apply the authenticated organization scope.
Qdrant
Each top-level application owns a Qdrant instance and one or more registered vector profiles. backbone_platform.vector_profiles maps a profile to an application, an endpoint setting key and its text, visual and layout collections. Jobs carry the profile key, never an arbitrary endpoint or credential.
Shared workers load the registered profile through data-service, then resolve its endpoint from the worker environment. A profile cannot be consumed by another application. New vector payloads include application, sub-vertical, organization, user and document identifiers.
Legacy rAInty points predate application and vertical payload fields. Similarity search preserves the original user-scoped filter for rainty-default; newly created top-level applications require application and organization filters.
Workflow routing
The document processing control plane remains shared. Workflow definitions and bindings select the application, while each run snapshot records the complete platform context. Bandi can therefore combine shared workers and dedicated workers without introducing a second control plane.