Build AI products with P6M
P6M works well as a backend for AI products because it provides product plumbing around the model: identity, access, knowledge, citations, events, audit, billing, support, and policy.
The model should not be the whole backend. Treat P6M as the system of record for who can do what, what knowledge is available, what was retrieved, what was delivered, what was charged, and what happened.
Recommended architecture
Use your app server for model calls and product-specific orchestration. Use P6M for reusable platform domains:
- Identity and auth for users, service accounts, API keys, and scopes.
- Workspaces to separate production, staging, tenants, or projects.
- Knowledge to store documents, run ingestion, query with citations, and inspect Memory Graph.
- Metadata to store app records such as assistants, threads, projects, saved prompts, and configuration.
- Events and notifications to deliver async workflow messages.
- Audit to record important security and product actions.
- Billing and usage to show customers their consumption.
- Support to build ticketing workflows or support experiences.
- Policy modules to enforce customer-specific rules before writes are accepted.
AI assistant pattern
For a cited assistant:
- Enable identity, metadata, knowledge, audit, and notifications.
- Create a knowledge collection for each product area, customer, or workspace.
- Add documents as Markdown or plain text.
- Ingest documents before they are queryable.
- At answer time, query P6M knowledge with the user's org, workspace, enabledServiceId, collectionId, and question.
- Send cited chunks to your model.
- Return the answer with citations from P6M.
- Store conversation metadata and audit important actions.
If your AI client supports MCP, use the P6M MCP server as the agent-facing bridge instead of teaching the model raw endpoint details. Your app can still keep durable state in P6M and call the public API directly where that is simpler.
The app should show citations to users. If the model says something that is not supported by a citation, mark it as uncertain or ask the user to clarify.
Multi-tenant product pattern
For a SaaS AI product:
- one P6M Org can represent your company or each customer account
- one Workspace can represent production, staging, or a customer tenant
- one Knowledge collection can represent a customer's uploaded knowledge
- service accounts should call P6M from your backend
- browser clients should call your backend, not hold long-lived service API keys
- role grants should be narrow and explicit
What to store where
Use Knowledge for source material that needs search, citations, or graph extraction.
Use Metadata for app records that your app wants to read or write directly.
Use Audit for security or operational history.
Use Events and Notifications for outbound messages and integration delivery.
Use Support for tickets and replies.
Use your model provider only for inference. Keep durable product state in P6M or your own application database.
AI agent skill
Give this instruction block to an AI coding assistant when you want it to build against P6M:
You are building a product on P6M. Use P6M as the backend for identity, auth, metadata, knowledge, notifications, audit, billing visibility, support, and policy modules.
First read the public OpenAPI spec at:
https://p6m.xyz/openapi/public.json
Use these conventions:
- authenticate with Authorization: Bearer <P6M_API_KEY>
- create or select a Workspace before storing app data
- enable each required domain before calling its APIs
- pass orgId, workspaceId, and enabledServiceId on domain calls when required
- use service account API keys from the backend only
- do not put platform tokens or long-lived service keys in browser code
- use Idempotency-Key on create requests that may be retried
- show Knowledge citations in AI answers
- store model-independent product state in P6M Metadata or Knowledge
- write audit events for admin, security, billing, or support-sensitive actions
For AI assistant features:
- store source docs in Knowledge
- ingest documents before querying
- query Knowledge for cited chunks
- pass only cited context to the model
- return citation metadata to the user
- inspect Memory Graph entities and relationships when the app needs entity-aware navigation or recommendations
Never invent endpoint paths. Use the OpenAPI spec as the source of truth.
Guardrails
- Do not store secrets in metadata.
- Do not expose service account API keys to browsers.
- Do not let the model decide billing, authorization, or policy outcomes directly.
- Do not hide citations for factual answers.
- Do not assume free-tier usage has an SLA.
- Do not use P6M support tickets for your own product unless you have enabled the support domain for that app.