PLATFORM / PRODUCT LANDSCAPE
Quiet Sky / light · source-backed

One platform. Many kinds of work.

Explore a capability, then follow its owner, contract and evidence. Availability differs by client and environment.

01
Select a component to inspect
CONNECT & COLLABORATECREATE & AUTOMATEUNDERSTAND & DECIDEOPERATE & GOVERNAgent sessions · tools. This tile groups product capabilities, not a deployed service.Assistant chatAgent sessions · toolsMessages · threads · membership. This tile groups product capabilities, not a deployed service.RoomsMessages · threads · membershipLive media · notes · assets. This tile groups product capabilities, not a deployed service.Meetings & ScribeLive media · notes · assetsMeetings · agenda · sources. This tile groups product capabilities, not a deployed service.CalendarMeetings · agenda · sourcesAuthor · build · host. This tile groups product capabilities, not a deployed service.AppsAuthor · build · hostDefinitions · versions · runs. This tile groups product capabilities, not a deployed service.WorkflowsDefinitions · versions · runsDiscover · approve · pin. This tile groups product capabilities, not a deployed service.Skills & MarketplaceDiscover · approve · pinJS · cron · goals · heartbeat. This tile groups product capabilities, not a deployed service.Agent automationJS · cron · goals · heartbeatEvidence · views · private memory. This tile groups product capabilities, not a deployed service.Knowledge & AskEvidence · views · private memoryPriorities · briefings · feedback. This tile groups product capabilities, not a deployed service.Command CenterPriorities · briefings · feedbackData · panels · layouts · sharing. This tile groups product capabilities, not a deployed service.DashboardsData · panels · layouts · sharingDirectory · hierarchy · work lens. This tile groups product capabilities, not a deployed service.PeopleDirectory · hierarchy · work lensPlatform · Knowledge · runtime. This tile groups product capabilities, not a deployed service.Admin surfacesPlatform · Knowledge · runtimeIdentity · subscriptions · usage. This tile groups product capabilities, not a deployed service.Account & billingIdentity · subscriptions · usageOAuth · secrets · artifacts. This tile groups product capabilities, not a deployed service.Connections & filesOAuth · secrets · artifactsDevices · approvals · notifications. This tile groups product capabilities, not a deployed service.Runtime & deliveryDevices · approvals · notifications
ExperienceServiceDataAI / infrastructureAccess
UpstreamSelectedDownstream
RelationshipConditional / futureExternal / unverified
01
Six repositories

Three clients; gateway, Knowledge and CC.

02
External owners

Matrix, BSG, UMS, meeting and workflow services.

03
Evidence, not rollout

656 inventory files; no production certification.

How the services connect.

Logical requests and source supply. External owners are explicit; not all routing hops or supporting calls are drawn.

02
Select a component to inspect
requests / eventsmessaging APIsbot JWTmodel callsretrievalmemory queryreads / actionstool executionhandoffown collectionoptional Slack L0Web experiences and client state; reaches the assistant and human chat through Matrix, plus product REST APIs.Web appNext.jsNative client that reuses the same routing method and backend contracts as web, including the shared Matrix path.Mobile appExpo / React NativeLoads the hosted web app and inherits its Matrix routing; supplies native desktop permissions.Desktop appElectron → hosted webMatrix carries human chat and client↔assistant messages; rooms/events route into the AIBot runtime, with meeting/call paths beyond AIBot.Messaging / callsMatrix + meeting servicesCoordinates assistant work and gateway requests; executes tools and relays events.AIBot runtimeSessions · tools · workflowsAgent loopGatewayVerifies the runtime bot JWT, derives the acting user identity, brokers authorized product-service calls (Command Center, rooms/membership, directory), and fronts durable stores — the memory index and user-content/file history — for query.Service bridgeBot Service GatewayRoutes authorized model requests. Also used independently by Knowledge and CC.Model gatewayLiteLLM routingEvidence and view service backed by per-user workspaces and immutable search revisions; retrieval uses hybrid semantic + full-text search.KnowledgeViews · evidence · retrievalDurable agent memory: a dual-write index — Postgres read path fronted by BSG plus a best-effort SQLite shadow — over embeddings and full-text for hybrid recall.Memory indexAgent memory · embeddingsOwn collection and insight pipeline; API results and user actions pass through BSG.Command CenterPriorities · people · agendaAgentCore authoring, shared app runners and generic MicroVM execution are separate axes.Execution servicesAuthoring · runners · sandboxesDockerAgentCoreMicroVMSupplies validated raw-source snapshots to Knowledge. CC can optionally fetch Slack L0.Brain DataImmutable L0 snapshotsKnowledge and CC have different source coverage and acquisition paths.Connected workSlack · mail · calendar · docsIdentity/hierarchy, per-user credentials and runtime placement support multiple services.Platform servicesUMS · Vault · OrchestratorCLIENTSMESSAGINGCOORDINATIONPRODUCT SERVICESSOURCE SUPPLY
ExperienceServiceDataAI / infrastructureAccess
UpstreamSelectedDownstream
RelationshipConditional / futureExternal / unverified
01
Shared client path

Web and mobile route through Matrix into the runtime with one method.

02
BSG fronts stores

Bot JWT brokering plus memory index and user-content history for query.

03
Sandbox backends

Execution runs in Docker, AgentCore or MicroVM by task.

Conversations are not one session.

Three state boundaries: Matrix rooms, agent execution sessions and Knowledge Ask. Calendar joins multiple sources.

03
Select a component to inspect
HUMAN COLLABORATIONASSISTANT & MEETING PROCESSINGMEETING INTELLIGENCE & PLANNINGmeeting contextGET / editagenda resultsMatrix owns messages, threads/events and membership. A room is not an agent execution session.RoomsHuman conversationLive media and meeting records are distinct authorities.Live meetingsSFU / media transportCalendar combines meeting records, CC agenda and caches. Calls redirects to Calendar.CalendarSource + record + inferenceAppend-only JSONL keeps execution history; compaction does not delete that history.Agent sessionsExecution keys · JSONLMeeting processing is not owned by AIBot. Scribe serves legacy sections or block/markdown modes.Meeting serviceProcessing & recordsMeeting preparation and inferred planning are produced by CC stages.CC agendaSynthesized preparationInitial GET loads Scribe; Matrix version/change events trigger another GET. No polling.Scribe change eventVersion signal, not contentMeeting notes display after processing and update through event-triggered refetch.ScribeNotes · edits · assetsAsk has its own session bodies, metadata and leases; it is not a Matrix room or AIBot JSONL session.Knowledge AskSeparate answer history
ExperienceServiceDataAI / infrastructureAccess
UpstreamSelectedDownstream
RelationshipConditional / futureExternal / unverified
01
Room ≠ session

Human state and execution state stay separate.

02
Scribe refresh

Event signals change; GET retrieves the body.

03
Calendar is a join

Source calendar, meeting record and CC agenda.

Authoring is not hosting.

Four separate execution axes: main agent, AgentCore authoring, shared app runners and generic MicroVM tools.

04
Select a component to inspect
REQUEST & AUTHORBUILD & PLACEMENTSERVE & PERSISTdelegatetool callauthoring APIBSGplacementapp filesserveThe main agent delegates app planning, coding and troubleshooting.App intentChat requestAgentCore authors app code; it is not the fleet that serves running apps.AgentCoreAuthoring sessionsClients list owned apps and call start/deploy operations.Owned appsDiscover · start · deployCLI bridges builder workflows to service contracts.Builder CLIPrepare authoring requestsCoordinates builds and placement on shared runners.App control planePrepare · build · place · startGeneric sandbox execution is a fourth, separate axis.Generic MicroVMTool sandbox — not app hostTenant EFS retains app and deployment files.Tenant EFSApp source + deployment treesShared runners host apps; AgentCore remains the authoring system.Shared-runner fleetHosts running appsPublic app routes front BSG/runner execution.Public app routeServed app experience
ExperienceServiceDataAI / infrastructureAccess
UpstreamSelectedDownstream
RelationshipConditional / futureExternal / unverified
01
AgentCore

Authors; does not host the public app.

02
Shared runners

Build, place and run tenant apps.

03
Tenant EFS

Source and deployment trees are distinct.

Three automation paths, not one engine.

Page-managed workflows, agent-authored JavaScript and runtime scheduling have different contracts and authorities.

05
Select a component to inspect
PAGE-MANAGED WORKFLOW SERVICEAGENT-ASSISTED AUTHORINGOTHER AUTOMATION PATHSAPIexecuteauthorsave onlyFeature flags select the workflow experience and engine.Workflows pageDefinitions & draftsWorkflow service is the sole draft/list store for page-managed workflows.Workflow V2Versions · catalog · publishPublished versions and runtime traces are distinct from local authoring state.Runs & tracesExecution recordsThe builder uses catalog schemas to author compatible definitions.Builder catalogDiscover available actionsPush transfers a workflow definition; it is not publish or run.Validate & pushSave a definitionRoom integration varies by selected service implementation.Room actionsEngine-dependent supportAgent-authored automation is separate from the page workflow service.JS automationAgent-authored programsScheduled agent turns are not workflow-service versions or runs.Cron & heartbeatScheduled agent workGoals coordinate continuing assistant work.GoalsLonger-running agent intent
ExperienceServiceDataAI / infrastructureAccess
UpstreamSelectedDownstream
RelationshipConditional / futureExternal / unverified
01
Store of record

Page drafts and lists live in workflow service.

02
Push ≠ publish ≠ run

Do not collapse authoring and execution.

03
Engine gates

Legacy, V2 and SVC support differ.

Discover broadly. Install deliberately.

Skills, tools and connector grants are different layers. A model decision is not an authorization event.

06
Select a component to inspect
DISCOVER & AUTHORIZEVALIDATE & PERSISTCONSUME & DISTRIBUTErequestverifieddiscoverdiscoverinvokescoped accessDiscovery finds candidates; it does not install or authorize them.Skill discoveryMarketplace searchOnly a trusted approval allows the installation path to proceed.Trusted approvalExplicit user authorizationMarketplace covers more than skills: Apps, panels and sharing also exist.MarketplaceApps · panels · sharingPinned, validated content is required before tenant installation.Integrity checksVersion · hash · manifestValidated skill instructions become tenant-pinned workspace content.Tenant-pinned skillInstall in tenant workspaceInstalling a skill does not grant access to an external connector.Connector grantsOAuth / Vault permissionsCore skills are not marketplace-installed content.Core skillsBundled instructionsSkill instructions guide the agent; executable tool schemas remain separate.Agent runtimeDiscovers skill instructionsTool calls are controlled by runtime policy and any required grants.Tool schemasExecutable capabilities
ExperienceServiceDataAI / infrastructureAccess
UpstreamSelectedDownstream
RelationshipConditional / futureExternal / unverified
01
Trust boundary

Explicit approval, not a model boolean.

02
Pinned artifacts

Version, hash and manifest are validated.

03
Three layers

Skill instructions ≠ tools ≠ connector grants.

A real surface, with multiple data paths.

Specs, live panels, variable options, layout persistence and sharing are implemented. Engines remain distinct.

07
Select a component to inspect
AUTHOR & DEFINEQUERY & RENDERPERSIST & DISTRIBUTEspecrenderqueryaccessBuilder creates dashboard specifications and supporting data/layout assets.Dashboard BuilderPanels · data · manifest · gridThe dashboard surface has concrete API clients, not just a product vision.Dashboard specsStructured panel definitionsWeb renders custom dashboards, edits layouts and applies cross-filters. Insights redirects here.Dashboard surfaceRender · edit · cross-filterDashboard viewers have data-source-specific execution paths.Source enginesSQL / Databricks pathsA separate viewer path owns saved config, queries, charts and migrations.Universal viewerSaved config & refreshTableau is an additional integration, not the universal dashboard backend.TableauSeparate integrationLayout writes are distinct from spec and data-query writes.Layout stateGrid persistenceShared dashboard access is independent of panel refresh and layout state.SharingGrant · revoke · consumeConsumers depend on specs, permissions, source availability and rendering behavior.Dashboard consumersSaved and shared views
ExperienceServiceDataAI / infrastructureAccess
UpstreamSelectedDownstream
RelationshipConditional / futureExternal / unverified
01
Implemented

Specs, live panels, variable options and editor.

02
Separate state

Data, panels, layout and sharing.

03
Multiple engines

Custom renderer, SQL viewer and Tableau.

Identity is not hierarchy. Admin is not one app.

Responsibility labels identify technical owners, not an unverified organizational RACI.

08
Select a component to inspect
IDENTITY & ORGANIZATIONAL CONTEXTAUTHORIZED PRODUCT LENSESTHREE ADMIN BOUNDARIESidentitylive scopeDirectory identity answers who a person is; it is not a reporting graph.People directoryFind a personUMS supplies hierarchy and identity enrichment to multiple consumers.UMS hierarchyReporting relationshipsCurrent scheduler eligibility is not a UMS user-enumeration loop.CC eligibilityAssignment + credentialsThe People lens is synthesized work context, not the directory or hierarchy itself.CC People lensSynthesized work contextOwner and allowed reporting scopes govern evidence access.Knowledge accessLive hierarchy + owner scopeThe web guard controls entry to an external admin iframe.Admin entitlementProfile-based guardThe external Admin Panel implementation is not in this workspace.Platform AdminExternal iframeKnowledge Admin manages Knowledge jobs and lifecycle separately.Knowledge AdminWorkspaces · jobs · evalsRuntime operational controls are not the Platform Admin console.Runtime controlsReset · restart · health
ExperienceServiceDataAI / infrastructureAccess
UpstreamSelectedDownstream
RelationshipConditional / futureExternal / unverified
01
Three meanings

Directory identity, reporting graph, People lens.

02
Private means self

Report persona is not manager evidence.

03
Three admin surfaces

External console, Knowledge Admin, runtime ops.

Ask, refuse, or just instructed.

What the bot must clear before acting. Some gates ask a human and block in code (fail closed); some refuse server-side with no ask; the rest are only a prompt instruction. Note where a gate degrades off Matrix or on autonomous turns.

09
Select a component to inspect
HARD GATES — ASK A HUMAN, CODE BLOCKSREFUSE GATES — SERVER SAYS NO, NO ASKPROMPT-ONLY + CAVEATS — NOT CODE-ENFORCEDthenthenthenvs promptvs promptvs promptA shell command missing the allowlist (or any command when ask=always) is blocked and forwarded to a human before it runs; elevated (“sudo”) mode is itself a gate — it needs tools.elevated.enabled + allowed + allowFrom.<provider>, else it is forced off.Shell command approvalAllow once · always · denyDelete / permanent-stop and any confirm-first action present a clickable card and wait; on the 3-minute timeout it returns no-answer and stops — it never auto-selects. Separately, in a group room a NON-owner using a Tier-2 tool triggers a real owner-approval card (5-min, per-room mutex) before it runs.Destructive confirmationask_question · delete / stopMarketplace install needs the user’s actual click (one-time ~5-min token); tenant-config needs an owner Apply on a diff (Matrix+owner+sender-bound, 5-min, optimistic-concurrency guard); workflows can park on approval()/choice()/prompt()/send(buttons). Publishing/sharing an app has its own server gates: a plugin needs an APPROVED version first, and only the app owner may share/update it.Install · config · workflow HITLSkill click · tenant Apply · approval/choice/promptSending to another agent (or spawning A2A work) is refused unless agent-to-agent is enabled and the target is on the allowlist — a config gate, not a human ask. A cross-tenant target is always forbidden, and a sandboxed sub-agent can only reach sessions it spawned.Agent-to-agent sendsessions_send · allowlistAdding or removing someone runs as the acting human: BSG’s invite-precheck refuses (owner not in room, invitee not a person, not a group, owner cannot invite) and Synapse enforces the caller’s own power level on kick. Deleting a room needs the caller to be a live room admin (403 not_room_admin) — a distinct gate from kick.Invite / kick a personBSG precheck · Synapse power levelSome actions are refused with no ask at all: a shell command that writes aibot.json is hard-blocked (use the config method), a mandatory deny (gateway, nodes) can never be re-enabled by a tenant, and every call made as a banned or marked-for-deletion user is 403/401’d server-side.Blocked-outright actionsConfig-write · mandatory deny · banned accountThe prompt tells the model to confirm (show recipient + content, wait for a matching yes) before messaging, emailing, broadcasting or a calendar invite to anyone but the current user; WHO you message is not code-gated. But WHERE is: a code policy blocks sends outside the bound room/provider unless cross-context is explicitly allowed, and in a channel chat only the owner may act in other rooms.Send to anyone but youMessage · email · channel · inviteSpending money, purchasing, publishing to a registry, or external writes (tickets, PRs, third-party APIs), and destructive ops like delete/force-push/DB changes are confirm-first instructions. One kind of spend IS code-enforced: provisioning a MicroVM runs a fail-closed credit check and refuses (402 credit-exhausted / 503) when the tenant is out of credit.Spend · external writesPayment · publish · tickets · PRsOff Matrix the ask tools are absent so confirm-first is prompt-only; autonomous turns (cron, goals, heartbeat) do not call ask_question and are gated only by session send-policy. Some things people expect to ask do not: replying to you, request_connection (your ask is the consent), device pairing (a human approves an inbound node). Secrets are their own model: in a group chat only pre-approved vault keys are usable, and any other key auto-requests approval.Where gates do not fireOff-Matrix · autonomous · not-a-gate
ExperienceServiceDataAI / infrastructureAccess
UpstreamSelectedDownstream
RelationshipConditional / futureExternal / unverified
01
Three kinds

Some gates ask and block (fail closed), some refuse server-side, most confirm-first are prompt-only — but a few things people call prompt-only have a real code block underneath (compute credit, cross-room sends, banned accounts).

02
Off Matrix

ask_question is unregistered, so every confirm-first action degrades to prompt-only; exec approval, cross-context and server-side refusals still apply.

03
Autonomous bypass

Cron / goals / heartbeat turns skip the ask gates; only session send-policy and the code refusals apply.

For reference · this bot vs single-developer coding agents

How this bot gates, next to Claude Code, Codex and Cursor

The coding agents are single-user, local-trust tools: they gate the machine and repo in front of one developer. This bot is multi-user and messaging-native, so it adds a whole dimension they lack — server-side refusals that run as the acting human (identity, tenant, power-level, credit, banned-account). The other split is where each one enforces: this bot and Codex lean on a sandbox + harness, Claude Code on tool + argument rules, Cursor mostly on the model plus an allow/deny list.

ActionThis botClaude CodeCodexCursor
Edit / write a fileRuns; sandboxed sessions get workspace access none / ro / rw; ro disables editAsk, unless acceptEdits mode or an Edit(…) allow ruleAsk (suggest) → auto (auto-edit / full-auto)Accept the diff, or auto-apply in auto-run
Run a shell commandexec approval: deny / allowlist / ask / auto / full; fails closed on timeout; writing aibot.json is hard-blockedAsk per command; allow-always persists to settings, argument-matched e.g. Bash(git commit:*)Ask (suggest / auto-edit); runs unprompted in full-autoConfirm per command; allowlist auto-runs, denylist blocks
Network egress from a commandSandbox default network none; elevated mode is an explicit gate to escapeNot gated (open)Blocked by the sandbox in full-auto; cloud runs use a network allowlistNot explicitly gated
Write outside the workspaceSandbox blocks it; dangerous bind mounts (/etc, ~/.ssh, docker sock) refusedScoped by Read/Edit path rulesBlocked by the sandbox (scoped to the working dir)Blocked by .cursorignore / dotfile protection
Web fetch / searchTools gated by profile (minimal/coding/messaging/full); tenant may narrow, never widenPer-domain gate, WebFetch(domain:…)Via the sandbox network policy—
Message / email someone elsePrompt confirm-first (who); code-enforced cross-context / cross-room block (where); off Matrix the ask degrades to prompt-onlyOut of scopeOut of scopeOut of scope
Destructive / confirm-first actionask_question card, 3-min, never auto-selects; in a group a non-owner triggers an owner-approval cardVia deny rules or a PreToolUse hookSandbox contains the blast radiusDedicated guard asks even in auto-run
Spend / provision computeMicroVM credit gate: 402 exhausted / 503, fail-closed; other spend is prompt-only———
Act on people / rooms / tenantsServer-side refuse: invite-precheck, Synapse power level, room-delete admin, cross-tenant block, banned / marked-for-deletion 403Not applicable (single user)Not applicableNot applicable
Full bypassexec mode full / elevated-full; autonomous turns skip the ask gates (still bound by send-policy + code refusals)bypassPermissions (no gate)full-auto (still sandboxed)auto-run mode
Enforcement layerHarness (Gateway filters tools by policy before the model) + server-side refusals in BSG / UMS + prompt for confirm-firstHarness: settings.json allow/ask/deny + hooksHarness: approval mode + OS sandbox (Seatbelt / Landlock+seccomp)Mostly model-mediated + allow/deny list

This bot’s column is drawn from the verified gates above; the other three are compiled from public documentation, not a source audit. The rows people expect to ask that this bot does not gate — replying to you, request_connection, device pairing — are covered in “Where gates do not fire.”

How information becomes useful.

Two independent pipelines. Arrows show information flow; the lower loop spans future runs.

10
Select a component to inspect
KNOWLEDGE / SOURCE EVIDENCE → DURABLE UNDERSTANDINGCOMMAND CENTER / WORK ACTIVITY → ATTENTION → FEEDBACKdirect evidence retrievalfuture runsfuture groupingRaw connector material retained as source objects, not user-facing answers.Source recordsL0 · immutable inputsConversation-aware L1 batches use capability-only Pi in the owner workspace, cumulative retries and exact citations. No generic shell/filesystem tools.L1 extractionDurable Pi batchesValidated content and indexes become visible through CURRENT publication.Published L1Evidence + indexSeparate scheduled/on-demand generation over the owner and allowed report memory.ViewsGenerated documentsRetrieves allowed evidence and synthesizes answers. L1 can be retrieved without a generated view.AskCited answersCollects Slack, Gmail, calendar, Matrix and meeting data; selected Slack traffic can use Brain Data L0.CollectOwn source inputsSource-specific model calls extract signals and check whether open work was resolved.SignalsExtract + resolveSynthesizes work stories and people context, incorporating existing active work and CC preferences.StoriesWork + people contextUses stories plus previous groups and feedback to build and assign priority groups.PrioritiesGroup + orderSeparate narrative/agent outputs and calendar preparation use story and calendar context.BriefingsDaily + meeting prepPersisted output is returned to product surfaces. Partial runs can retain usable results.DeliverProduct UIRecent feedback influences future priority groups; consolidation writes CC preferences that influence future stories.Feedback & preferencesRate → consolidate → reuseSEPARATE AUTHORITIESKnowledge: user workspace + SQLite indexes / Command Center: Postgres results + feedback
ExperienceServiceDataAI / infrastructureAccess
UpstreamSelectedDownstream
RelationshipConditional / futureExternal / unverified
01
L0 → L1

Source material becomes attributed memory.

02
Parallel outputs

Priorities and narratives are siblings.

03
Freshness

Reprocess ≠ regenerate ≠ retrieve.

Evidence and private memory have different rules.

Durable ingestion, immutable publication, authorized retrieval and self-only assistant memory.

11
Select a component to inspect
EVIDENCE INGESTION & PUBLICATIONSERVING & PRIVATE CONTINUITYDURABILITY & LIFECYCLEpublishdocumentsself onlydurable turnscommitUnchanged source-content hashes are no-ops even after a prompt edit.L0 source inputsContent-hash change detectionExtraction uses owner workspace capabilities, not generic shell/filesystem tools. GitHub commits batch by repo/UTC day with exact citations.Durable L1 batchesConversation-aware extractionPublished revisions expose attributed evidence and reusable search artifacts.Published evidenceL1 + search artifactsViews are derived documents with a separate generation lifecycle.Generated viewsScheduled / on demandAsk retrieves authorized work evidence. Persona is guidance, never performance evidence.Ask & retrievalAnswers with evidenceMemory and persona are self-only. A manager cannot retrieve a report’s persona.Private Ask memoryRemember · forget · styleBodies live in workspace storage; Postgres stores metadata/leases.Ask session bodiesWorkspace-owned historyDurable execution and publication commits use Knowledge control-plane state.DBOS + control DBDurable commits / queuesWorkspace-derived cleanup and database retention are distinct lifecycle work.Cleanup & retentionDerived data + DB lifecycle
ExperienceServiceDataAI / infrastructureAccess
UpstreamSelectedDownstream
RelationshipConditional / futureExternal / unverified
01
No automatic backfill

Prompt edits do not change L0 hashes.

02
Two memory roles

Work evidence versus private assistant guidance.

03
Separate pipelines

No proven Knowledge L1 → Command Center feed.

Follow contracts, not just arrows.

A review method with two source-backed examples. Traces model relationships; they do not calculate guaranteed blast radius.

12
Select a component to inspect
METHOD / CONCEPTUAL REVIEW SEQUENCEEXAMPLE A / CHANGE THE KNOWLEDGE EXTRACTION PROMPTEXAMPLE B / ADD A NEGATIVE PRIORITY REASONinspecttestreplay?publishreasonpersistStart with the affected surface, selected engine/flag and technical authority.1 · Define the changeSurface + intended behaviorInspect each boundary for validation, authorization, defaults and saved state.2 · Follow the contractSchema + permissions + statePlan compatibility tests and any data replay or cache invalidation explicitly.3 · Verify the rolloutRegression + migration + gatesSaved configuration may override the default; changing the file alone may not change the effective prompt.Effective L1 promptDefault versus saved configUnchanged content is skipped; historical re-extraction needs an explicit plan.Explicit reprocessingContent hashes still applyDownstream views may need regeneration; Ask can retrieve evidence directly.Regenerate & evaluateViews / retrieval / AskOnly the first negative tag is sent today, even if the UI selects more.Client reason pickerWeb + mobile serializationBoth server layers validate reason values. UI-only additions are rejected.Closed allowlistsGateway + CC validationRecent feedback affects priority grouping; consolidated CC preferences influence future stories.Future preferencesRate → consolidate → reuse
ExperienceServiceDataAI / infrastructureAccess
UpstreamSelectedDownstream
RelationshipConditional / futureExternal / unverified
01
Prompt edit

Effective config, replay, publish, regenerate, evaluate.

02
Reason edit

Clients, two validators, persistence and future context.

03
Trace limits

Selected links include conditional and future paths.

Where the intelligence lives.

Each feature owns its instructions. Model access is shared; behavior is not.

13
Select a component to inspect
INDEPENDENT AI CONSUMERSMODEL CAPABILITIES / ACTUAL PROVIDER ROUTES VARY BY ENVIRONMENTmodel requeststool-specificCombines conversation context, routing, tool policies and skills; can choose model paths dynamically.AssistantDynamic agent loopChatToolsBuildersSeparate model/effort settings for L1 extraction, compose, Ask, retrieval and embeddings.KnowledgeExtract · compose · answerL1 promptView promptAskSeparate prompts and per-substage model/effort settings; per-user LiteLLM credentials.Command CenterStage-by-stage inferenceSignalsGroupsBriefsThere is no single universal platform prompt. Prompt contracts and output validation live with their consumers.Feature instructionsPrompts + schemasRoutes requests using the effective alias, endpoint and credentials supplied by the consumer.LiteLLM gatewayAuthorized model routingAliasesCredentialsLimitsModel access must retain the correct tenant/user credentials and task permissions.Access & isolationTenant credentials + policyModel families used for inference. Exact effective models require environment verification.Text & reasoningGenerate · classify · synthesizeRepresent saved content and queries for search. They are distinct from chat models.Embedding modelsSemantic search vectorsDocumented runtime tools use their own provider/model paths. This is not a claim that every media call uses one route.Media modelsImages · audio · other toolsPROMPT ≠ MODEL ≠ AGENT RUNTIME ≠ SAVED MEMORY
ExperienceServiceDataAI / infrastructureAccess
UpstreamSelectedDownstream
RelationshipConditional / futureExternal / unverified
01
Prompt

Instructions for a specific job.

02
Runtime

Coordinates context and tools.

03
Model

Supplies inference, not data ownership.

Where the work runs.

Deployment inventory, not a verified network topology. Physical placement and replica counts are omitted.

14
Select a component to inspect
KUBERNETES WORKLOAD TYPES / CO-LOCATION NOT ASSERTEDnetwork accessmodel / tool callsCC via BSGretrieval dependencyingest handoffClients access hosted web/product services and assistant channels.User devicesBrowser · mobile · desktopLogical access boundary. Exact production ingress, load balancers, DNS and route placement were not audited.Access / routingPublic and internal service entry pointsHelm service/workload templates exist for hosting the web application.Web workloadNext.js applicationRuntime placement and tenant contexts are coordinated with external orchestration.AIBot runtimeAgent / gateway executionServes workspace content and authorized APIs. Separate DBOS-worker deployment templates are present.Knowledge APIContent accessRuns checkpointed ingestion/view workflows and reads/writes shared workspace revisions.DBOS workersDurable KB jobsHTTP API, scheduler and bounded worker loops run in the same process; jobs are persisted in Postgres.CC workloadAPI + job workersService identity, organization hierarchy, credentials and Orchestrator dependencies support the workloads.Core servicesBSG · UMS · VaultSeparate LiteLLM model access, AgentCore authoring, shared-runner app hosting and MicroVM tool execution. App source/deployments use tenant EFS.External executionModels · app executionProduces source snapshots in the shared workspace and hands off ingestion to Knowledge.Brain DataSource producerCanonical workspace content includes evidence, views, private assistant memory and Ask session bodies; search artifacts support serving.Shared workspaceL0 · L1 · views · Ask bodiesKnowledge control/run metadata, Ask metadata/leases and DBOS state; canonical Ask bodies stay in the workspace.Knowledge control DBPostgres · metadata / leasesCC source projections, run outputs, durable job queue and feedback state.Command Center DBPostgres · queue / results / feedbackPERSISTENCE / LOGICAL OWNERSHIPSUPPORTING OPERATIONS Config / secrets · service accounts · metrics / traces · build & deployment
ExperienceServiceDataAI / infrastructureAccess
UpstreamSelectedDownstream
RelationshipConditional / futureExternal / unverified
01
Knowledge

API + configurable DBOS workers.

02
Command Center

API, scheduler and worker share a process.

03
Not asserted

Regions · replica counts · physical DB layout.

The supporting capabilities matter too.

Account, billing, access, files and execution controls are part of the platform—not one undifferentiated gateway.

15
Select a component to inspect
ACCOUNT & COMMERCIAL ACCESSCONTENT & DELIVERYAGENT TOOLS & OPERATIONSauthorizeAccount flows establish user context and lifecycle boundaries.Account lifecycleAuth · onboarding · deletionCommercial state and usage visibility have distinct service contracts.Billing & usageSubscriptions · payment · topupsPer-user secrets and grants support authorized integrations.Vault & connectionsSecrets · OAuth grantsFile attachments and generated artifacts participate in assistant work.Files & artifactsInputs and generated outputsClients differ in delivery and permission behavior; Electron loads hosted web.NotificationsUnread · desktop · channelsMobile main is the baseline; design-revamp routes are secondary branch evidence only.Native clientsMain baseline ≠ feature branchTools have provider-specific execution paths and capabilities.Research & mediaResearch · browser · voiceApproval, tenant agent routing and device execution define additional trust boundaries.Execution controlsApprovals · agents · devicesOperational diagnostics help inspect runtime behavior and failures.Health & telemetryUsage · logs · diagnostics
ExperienceServiceDataAI / infrastructureAccess
UpstreamSelectedDownstream
RelationshipConditional / futureExternal / unverified
01
Lifecycle boundaries

Accounts, billing, files and credentials differ.

02
Runtime breadth

Research, browser, voice, devices and approvals.

03
Branch honesty

Mobile feature routes are not mainline parity.