Step 1
Qualify the tenant and the data sensitivity
A BrainCaps is not opened as a generic workspace. The first step is to classify the tenant, the expected data classes, and the isolation tier that the operating model must support.
Creation and ingestion
A BrainCaps is created as a controlled memory perimeter, not as a blank chat space.
The public surface should make the product journey legible: who opens access, how the tenant boundary is provisioned, how ingestion becomes trustworthy memory, and which gates must close before sensitive customer content goes live.
Simple rule
PortalHQ opens the shared journey. BrainCaps provisions the product perimeter. The customer only sees the workspace once that boundary is coherent.
Creation flow
What has to happen before a customer really has a BrainCaps.
The path matters because it prevents shell concerns, operator shortcuts, and business data boundaries from getting mixed together.
Step 2
Activate the product in PortalHQ
PortalHQ owns the shared shell, team membership, billing state, and activation. BrainCaps should receive a resolved customer route, not rebuild those layers locally.
Step 3
Bind the BrainCaps perimeter
The product must resolve the right tenant boundary, entitlements, retention defaults, and operator guardrails before customer content starts flowing.
Step 4
Open the customer workspace and start controlled ingestion
Only then should the customer land in braincaps-app, where ingestion state, memory behavior, usage, and product-scoped settings become visible.
Ingestion modalities
Content ingestion should be explicit, observable, and reversible.
The customer should understand how material enters BrainCaps, how it is transformed into memory, and what guardrails stay attached to it.
Document uploads and controlled imports
The customer needs explicit ingestion entry points, not a vague promise that any file can be dropped anywhere without consequence.
Connectors with visible pipeline state
Connectors should show whether a source is healthy, degraded, waiting on credentials, or blocked by product policy.
Foundation parsing behind the product boundary
Parsing services stay behind BrainCaps API and foundation endpoints. The customer surface should expose outcomes, provenance, and guardrails rather than parser-brand sprawl.
Retention, provenance, and correction rules
Every ingestion path needs a visible story for source lineage, retention intent, and what happens when content must be corrected or deleted.
Go-live gates
Sensitive customer rollout needs explicit proof gates.
Commercial momentum is not enough. A real go-live requires isolation, privacy, AI governance, and evidence readiness to converge.
Isolation gate
T1 stays internal-only. Standard customer tenants require at least T2 discipline, and sensitive or regulated cases push toward T3 expectations.
Privacy gate
GDPR routines such as retention, deletion, export, subprocessor control, and data-subject request handling need named owners before go-live.
AI governance gate
Any AI-enabled behavior needs a use-case review, capability inventory, and explicit boundary checks before sensitive customer material is ingested.
Evidence gate
Claims about readiness, health, entitlements, and operator restrictions should be supportable by evidence packs rather than by commercial language alone.
Next useful jump
Once this path is clear, the next conversation is governance depth: privacy routines, AI accountability, operator boundaries, and the evidence expected before sensitive tenants go live.