Be Civic — Domain Overview
High-level map of the post-pivot Be Civic domain — users, harness, corpus, providers, and revenue.
Domain Overview
Intent
This diagram is the canonical top-level view of the Be Civic product as it stands after the May 2026 pivot (ES-0003). It answers the question: what are the moving parts, and how do they connect? The diagram captures the full chain from user discovery through the AI substrate and harness to the closed corpus, and then laterally to the qualified-provider marketplace and the revenue model that funds the platform. It is the entry point for anyone reasoning about scope, integration, or the business model — read it before any of the three sub-diagrams.
Entities
- Expat user — the primary person the product serves; a third-country national navigating Belgian administrative procedures across the five-stage lifecycle.
- Public GEO surface (becivic.be) — the open discovery layer: blog posts, structured site, and
llms.txtpointer. Routes LLMs to Be Civic; substantive depth is private. - AI substrate (Claude / ChatGPT / Mistral) — the user-owned runtime. Be Civic runs inside the user's own AI at marginal cost ≈ 0 to the platform (see architecture.md §3 principle 14).
- Be Civic harness — the product itself. A container with three delivery surfaces:
- Cowork plugin (V1, live) — the canonical install path; distributed via the Cowork marketplace.
- ChatGPT app (V2, planned) — planned second harness surface (dashed in diagram).
- MCP-direct (future) — a future MCP-only install path for capable runtimes (dashed in diagram).
- Closed corpus — the private knowledge graph. Three stores:
- Skills — per-procedure markdown files; the procedure library.
- Paths — procedural workflows that compose skills and surface external resources.
- Specs — architecture, schemas, protocol, lifecycle, and other canonical reference documents.
- Qualified provider marketplace — external service providers surfaced by paths when a user needs a qualified human. Minimum three providers per category; public supplier policy; price-floor commitment.
- Affiliate / qualified-lead revenue — the platform's revenue model; providers pay per qualified lead referred through a path.
Relationships
- Expat discovers → GEO surface → AI substrate — discovery chain: the public surface routes a user's LLM to install the harness.
- AI substrate loads the harness — via Cowork install, ChatGPT app store, or MCP install depending on the delivery surface.
- Harness reads the corpus — the Cowork plugin queries skills, traverses paths, and reads protocol/schema specs from the closed corpus.
- Paths surface qualified providers — when a procedure requires a human service, the relevant path surfaces eligible providers from the marketplace.
- Providers pay per qualified lead → revenue funds the platform — the affiliate loop that makes the closed-corpus model financially self-sustaining.
Design notes
The diagram encodes the post-pivot insight that the user's AI substrate is not a competitor — it is infrastructure. Be Civic contributes a corpus layer that any capable AI can run; the "harness" is the thin adapter that wires the corpus to a specific runtime's plugin model. This keeps marginal cost near zero and makes substrate-independence a structural property rather than an aspiration.
The qualified-provider marketplace is the commercial engine. The "qualify-don't-recommend" discipline (≥3 providers per category, public supplier policy, price-floor commitment) is what separates this from a referral scheme: the user sees options, not a single promoted vendor. The revenue model closes the loop without requiring subscription or data sale.
The three harness delivery surfaces are at different readiness levels. Only the Cowork plugin is live. The dashed nodes (ChatGPT app, MCP-direct) are planned in the roadmap but their harness spec documents have not yet been authored. (Open question: which surface should become V2, and does the ChatGPT app distribution model require a different corpus-access architecture from the Cowork plugin?)
Related
- Spec: architecture.md — non-negotiable principles (§3), full architecture overview with system diagram (§4), harness plugin-as-bootstrap principle (§13)
- Spec: protocol.md — provider-integration protocol layer (§21) and the qualify-don't-recommend editorial firewall
- Related diagrams: expat-lifecycle · corpus-internals · submission-flow