Platform Docs

Membloc AI Infrastructure Benchmark Plan

/platform/membloc-ai-infra-benchmark-plan

Membloc AI Infrastructure Benchmark Plan

Benchmark source: TOJI ai-pragma public page. Goal: adapt the useful AI-agent infrastructure pattern to Membloc without copying its product surface one-to-one.

1. Why this matters

Membloc is already moving from a single consumer app into a platform:

membloc-app is the family-facing Flutter client.
membloc-app-engine is the Go backend for auth, family, modules, runtime APIs, memory, calendar, archive, files, publisher/admin, and webhooks.
membloc-developer-portal gives publishers an operational surface.
membloc-docs publishes platform and operations documents.
jmcunst-membloc-vault stores execution history, proof notes, and reusable playbooks.

The next pressure point is not just "add an AI feature." The real demand is to install an AI-capable infrastructure layer so product development, support, module review, family operations, and platform administration can all reuse the same knowledge and automation base.

2. What to benchmark from ai-pragma

ai-pragma is useful as an infrastructure reference because it frames AI as a system, not as a chatbot widget.

ai-pragma idea	Membloc adaptation	First Membloc owner
Relay	Chat, support, developer portal, admin actions as agent entry points	`membloc-app`, `membloc-developer-portal`
Core	LLM orchestration and tool routing behind internal APIs	new AI service boundary
Tracker	Tickets, review tasks, support cases, QA findings, module publishing workflow	`membloc-app-engine`
Brain	RAG over docs, playbooks, tickets, memories, modules, code, and decisions	new knowledge index
Agents	Bounded assistants for support, module review, QA, docs, family ops, and developer ops	AI runtime
Feedback loop	Every resolved ticket, PR, QA result, meeting note, and support answer becomes retrievable context	ingestion pipeline
Infra stack	Docker first, optional Kubernetes later, observability from day one	`membloc-app-engine` ops

The most important lesson: Brain must be a shared platform service. If every feature calls an LLM directly, Membloc will get duplicated prompts, inconsistent permission checks, and unreusable history.

3. Target Membloc shape

Users / Operators / Publishers
        |
        v
Membloc surfaces
  - App chat and family flows
  - Developer portal
  - Admin/publisher review
  - Support/helpdesk
        |
        v
AI Gateway
  - Auth context
  - Policy checks
  - Prompt and tool contracts
  - Model provider routing
        |
        +--> Tracker
        |     - support tickets
        |     - module review tasks
        |     - QA findings
        |     - publisher requests
        |
        +--> Brain
        |     - Postgres records
        |     - docs and vault notes
        |     - module manifests
        |     - support history
        |     - embeddings / graph / metadata search
        |
        +--> Tools
              - app-engine APIs
              - docs search
              - module validation
              - notification draft
              - support draft

4. Implementation lanes

Lane A: AI Gateway

Create a narrow server-side boundary before adding any user-facing AI feature.

Responsibilities:

Accept a verified user/session context from existing auth.
Enforce family, publisher, admin, and module permissions before retrieval or tool execution.
Route to one or more model providers through server-side configuration.
Log request metadata without storing raw secrets or unredacted private content.
Expose stable internal contracts, for example:
- POST /api/ai/assist
- POST /api/ai/draft-support-reply
- POST /api/ai/module-review
- POST /api/ai/family-summary

Do not put model API keys in Flutter, WebView modules, or the developer portal.

Lane B: Brain

Start with a small Brain that indexes what Membloc already owns.

Initial sources:

docs/
membloc-docs/content/
jmcunst-membloc-vault/13 Playbooks/
jmcunst-membloc-vault/12 Proof of Work/
membloc-app-engine database entities:
- modules
- publisher records
- reviews/readiness checks
- memories
- archives
- calendar events
- channel messages, only where policy allows

Recommended first storage shape:

Keep canonical records in PostgreSQL.
Add ai_documents, ai_chunks, ai_ingestion_runs, and ai_retrieval_audit tables.
Use Postgres full-text search first for deterministic MVP search.
Add vector search only after the ingestion and permission model is stable.

This avoids premature Qdrant/graph complexity while preserving the future path toward vector + graph retrieval.

Lane C: Tracker

Membloc already has publisher/admin workflows and webhooks. Extend those instead of inventing a separate tracker.

First tracked objects:

module review tasks
support tickets
QA findings
app-engine migration tasks
publisher onboarding checks
AI-generated draft approvals

Every agent action should produce a human-readable artifact:

draft answer
review checklist
task summary
escalation reason
source citations
approval state

Lane D: Agents

Begin with bounded agents that draft and recommend. Avoid autonomous production actions until audit and rollback paths exist.

Recommended first agents:

Support Draft Agent
- Reads docs, playbooks, and support history.
- Drafts Korean/English answers.
- Opens or updates a support ticket only after explicit operator action.
Module Review Agent
- Reads manifest, permissions, screenshots, privacy/support URLs, webhook declarations, and app-engine policies.
- Produces review readiness findings for publisher/admin.
Docs/Playbook Agent
- Converts completed work, incidents, and QA notes into docs/vault drafts.
- Keeps platform docs and operation playbooks aligned.
Family Ops Agent
- Summarizes family channels, memories, calendars, and archives within strict family RBAC.
- Never leaks one family scope into another.
Dev Ops Agent
- Summarizes failing checks, smoke tests, release readiness, and migration steps.
- Can suggest commands; production execution remains human-gated.

5. Infrastructure phases

Phase 0: Design guardrails

Define data classes: public docs, internal ops, family-private, publisher-private, admin-only.
Define which classes can be embedded, summarized, retained, or exported.
Define audit events for retrieval and tool execution.
Add an AI provider abstraction to avoid coupling app-engine to one vendor.

Exit criteria:

AI API keys are server-only.
No user-facing autonomous action exists yet.
Permission model is documented.

Phase 1: Local Docker AI stack

Extend local development with optional services:

ai-gateway or app-engine internal AI package
Postgres tables for ingestion metadata
local ingestion CLI for docs/vault
optional observability sink

Keep this phase Docker Compose based. Kubernetes is unnecessary until service count, uptime, and scaling pressure justify it.

Exit criteria:

Developer can run ingestion locally.
Developer can query docs/playbooks through an authenticated local API.
Retrieval results include source references.

Phase 2: Internal assistants

Add non-customer-facing assistants first:

module review draft
support reply draft
docs/playbook draft
release/QA summary

Exit criteria:

Drafts are useful without being auto-applied.
Every answer carries citations or source IDs.
Admin can inspect retrieval/audit logs.

Phase 3: Product AI features

Expose selected AI features to users after internal reliability is proven:

family memory recap
calendar/task summary
channel-to-memory/archive assistant
module recommendations
helpdesk assistant

Exit criteria:

Family RBAC is enforced in retrieval.
Sensitive data retention policy is implemented.
User-facing AI output has feedback/reporting controls.

Phase 4: Scaled platform AI

Only after phases 1-3:

vector index
graph relationships
agent tool execution
queue-backed ingestion
model observability and evaluation
Kubernetes deployment, if Docker Compose becomes the bottleneck

6. What not to copy

Do not copy ai-pragma's full infrastructure stack immediately.

Avoid at the MVP stage:

Kubernetes-first deployment
OpenStack dependency
separate graph DB
multiple workflow engines
autonomous PR/merge/deploy agents
direct LLM calls from frontend clients
broad "AI assistant" endpoints without permission-specific contracts

Membloc already has a working backend, database, docs, portal, and operational notes. The first benchmark win is to unify those assets into a permission-aware Brain, then attach small agents to existing workflows.

7. Recommended first slice

Build AI Infrastructure Slice 1: Docs/Playbook Brain + Support Draft.

Scope:

Add an app-engine AI package or service boundary.
Add ingestion metadata tables.
Add a docs/vault ingestion command.
Add retrieval over platform docs and playbooks.
Add an authenticated support-draft endpoint.
Add tests for permission boundaries and source citation behavior.
Add docs page explaining operator workflow.

Non-goals:

no vector DB yet
no customer family data ingestion yet
no autonomous ticket mutation
no production action execution

Why this slice:

It proves the Brain pattern with low privacy risk.
It helps real development and support immediately.
It creates the shared foundation needed by later family, module-review, and dev-ops agents.

8. Open decisions

Whether AI Gateway lives inside membloc-app-engine first or as a separate service.
Whether Slice 1 uses pure PostgreSQL full-text search or adds a vector extension.
Which model provider contract is allowed for Korean support content.
Which vault folders are safe to ingest into internal Brain.
Whether support tickets should be represented in app-engine database or an external tracker.

9. Minimum verification

For the first implementation slice, completion should require:

go test ./... in membloc-app-engine.
Local ingestion run against sample docs.
Retrieval result includes source IDs and snippets.
Support draft endpoint refuses unauthenticated requests.
Retrieval audit rows are written for AI requests.
No frontend bundle contains model provider keys.

SDK assets

Static SDK files

JavaScript runtime and TypeScript definitions are served from this docs app.

membloc-sdk.js membloc-sdk.d.ts