Point One Zero Platform architecturev11 · generated viewSign in to edit
Platform Layers › L2 Solution

L2 Solution

Where this layer sits on the architecture; the client plane band to its right shows the values it reads.

P1Z Platform ArchitectureOne reusable platform, one customization plane, equal partners: the platform is what P1Z builds once; the plane is what makes it a client's own · v2.5P1Z REUSABLE PLATFORMbuilt once, every client runs these same seven layers, unchangedCLIENT CUSTOMIZATION PLANEthe only per-client build, values, never codeLifecycle: PLAN (EA assessment fills the binding) → RUN (operate)1. ExperienceAMBIENT · CONVERSATIONAL · CROSS-CHANNELChatWeb AppDesktopMobile AppVoicePhone / Call CenterEmbedded in ToolsMCP HostsClaude, CopilotOutput & Format Rendererstructures from Knowledge · templates from the PlaneShared UI Coreone core behind every P1Z shell · cross-channelcontinuityChannel Mix & Notificationschannels on/off per client · proactive rulesFeedback Captureedits & rejections → eval storeC1. ExperienceVALUES, NEVER CODEChannel Mixon/off per audienceHouse Templatesbranding & layoutsOutput FormatsTone & LanguageNotification RulesEmbedded Surface Selectionwhich work toolsNORTH-FACING PLATFORM MCP GATEWAY, the whole platform exposed as an MCP SERVER to any host above: agents, use cases and UI resources as tools; allcode and business logic stays server-hosted.Per-tenant endpoint · tenant auth · host allow-list2. SolutionCLIENT-BLIND CODE · CLIENT-AWARE EXECUTIONOrchestratordeterministic, routes, gates, never authorsBusiness Agentsjudgment under guardrails; face the gatesWorkflowsdeterministic multi-stepCopilotshuman-driven assistSkillsone per use case, on demandDomain Rule Libraryimplements what Knowledge declares, computed once, cited everywhereSubagent Workersinternal; bounded summary contractsDetermination rule: any task with a testable right answer is deterministic code. Agents get judgment only, the last resort, not the firstdraft.C2. SolutionVALUES, NEVER CODEUse-Case Activationwhich agents are onOrchestration Modeserial vs parallel per use caseHITL Placementwhere humans reviewCustom Workflow Compositionreusable agents, never new codeOverride & Exception RoutingOverlay Selection3. KnowledgeCLIENT-BLIND · VERSIONED RELEASES ONLYIndustry OntologiesPE today, healthcare next, stable IDsFunctional Ontologiescross-industry: finance ops, legal, reportingP1Z Benchmarkseval outcomes, gate metrics, cycle-time normsPromotion Gateanonymize → aggregate → rights check → human review → versioned releaseCurated Consulting Benchmarksage-old priors as versioned dataC3. KnowledgeVALUES, NEVER CODEOntology Version Pinthe exact release this client readsOverlay Selectione.g., growth equityStage & Gate Name Mappingthe client's languageBenchmark Scope & Data-Rights Clausewhat telemetry may be promoted4. Intelligence (the AI layer)VENDOR-AGNOSTIC · SWAPPABLEModel Routerthe portability boundaryFoundation LLMsSmall Language ModelsEmbeddingsRerankersThis thin layer absorbs model progress, models upgrade, nothing above changes. AGI-readiness is a one-layer swap, not a rebuild.C4. IntelligenceVALUES, NEVER CODEModel Tier PreferenceCost Ceilingsthe router enforces themLatency TargetsApproved-Vendor ListData Sensitivity Boundarywhich classes reach which tier5. IntegrationAGENT TOOL CALLS & API CALLS ENTER HERESouth-Facing MCP Tool Serversplatform acts as MCP CLIENT here, one server per source; permissions onceAPI Gatewayoutbound external API calls; rate limits, retriesConnector Librarypre-built: Egnyte, SharePoint, Airtable, APIsSync EngineSource Catalogsources · access rulesETL, Batch & Streaming TemplatesSchema-Mapping ToolkitDead-letter HandlingMiddleware between everything above and the data below. A missing connector is BUILT into the library and SELECTED on the plane.C5. IntegrationVALUES, NEVER CODESource System SelectionCredentials & OAuth GrantsData ContractsField Mappingsclient schema → taxonomySync Schedules & ModesCustom Connector Selectionfrom the library6. Data & DocumentsPER-TENANT ISOLATION · DATA ENGINEERINGVector DB ServiceDocument Store ServiceData Warehouse ServiceRetrieval APIsIndexing & Taxonomystructures from KnowledgeSystems of RecordERP, CRM, fund adminDocument SourcesVDR, SharePoint, emailUnstructured Datanotes, transcripts, recordingsExternal Data Providersmarket & benchmark feedsTenant stores are reusable templates; dashed boxes are the SOURCE ESTATE they front, reached only through Integration (L5).C6. Data & DocumentsVALUES, NEVER CODETenant Store Instancesthe client's actual dataSource Estate Inventorytheir SoRs, VDRs, warehouses, feedsDocument Taxonomy Mappingtheir docs → the taxonomyData Residency & RegionsRetention & Legal Hold7. Environment (the Harness)BUSINESS-BLIND · SELF-OPTIMIZINGAgent Loop & Run Contractsend state + token budget; over-budget = killGuardrail Mechanics4 locks: instructions < hooks < scopes < gatesSession & Memory Machinerycontext packs, compaction, memory storesObservability & Eval Infracontent-blind traces; eval runners; A/BIdentity & Tenancyservice identities; isolation tests in CICI/CD, ADLC & SSRA Skeletonrepo templates: constitutions, skills, agent defs; sandbox →eval gate → promotion → registry deploySecrets & KMSper-tenant keysSRE & Incident Opsrunbooks, DR, on-callFuture-proofed and model-agnostic by construction. Self-optimizing via the operational loop, every tuning is a versioned config change throughCI; silent drift is a defect.C7. EnvironmentVALUES, NEVER CODETenancy & Account MappingIdentity ProviderEntra / Cognito / OktaToken Budgetsper use caseGate Approver RolesAlerts & Escalation TimersNo code in the plane, values only. Custom logic is a Solution-layeroverlay, SELECTED here.slotsandvaluesKNOWLEDGE LOOP, telemetry & evals, gatedOPERATIONALLOOPlearns how to run -versioned, never silentDeferred and open items are not drawn and never lost: they live on the Decision Register page, with activation triggers.How to read this diagram• Left column: what P1Z builds once and every client reuses. Right column: the values one client fills in. The double-headed connectors between them are that exchange. Samestructure on both sides, only the contents differ.• Two MCP boundaries. The north gateway (between layers 1 and 2) is where hosts like Claude or Copilot connect; all code stays on the server. The south tool servers (layer5) are where agents reach data. Tenant identity is checked at the north, source permissions at the south.• Read top to bottom to follow a request. Build bottom to top; setup starts at layer 7. The knowledge loop promotes gated telemetry into benchmarks. The operational looptunes the harness. The two loops never mix.• Agents live in layer 2 and are reused unchanged; the plane only switches them on and arranges them. No code ever enters the client column.Point One Zero · generated view, scripts/generators/build_p1z_arch.py · v2.4 · seven layers + client plane

L2 Solution CLIENT-BLIND · KNOWLEDGE-PINNED

The working tier: one deterministic orchestrator, business agents (judgment under gates), workflows (deterministic multi-step), copilots, one skill per use case, the domain rule library, and subagent workers on bounded summary contracts.

  • Orchestrator: routes, validates, gates, sequences, records lineage, never authors content
  • Business agents own outcomes and face the gates; subagents are internal implementation
  • Domain rule library implements what Knowledge declares, computed once, cited everywhere
  • Determination rule governs everything here (see below); sandbox + promotion checklist live in the ADLC, not in the architecture

Boundary test: reused unchanged across clients, a client-specific edit to this layer is a defect.

Plane parameters: orchestration mode · HITL placement · overlay selection

The determination rule, which decides what is built as an agent and what is built as deterministic code, governs everything in this layer. It is recorded in full in Governance, on the Decision Register page.

Client-specific configuration for this layer is specified band by band in Client Delivery, C2 spec: every input with its binding key, generated artifact, and verifying check.

Component reference

Orchestrator

The deterministic routing and control unit above all agents: validates inputs, dispatches, enforces gates, sequences the dependency graph, records lineage. It never authors content.

ImplementationA deterministic state machine on the agent runtime with a capability-to-agent routing table. Watch the God Orchestrator antipattern: orchestrator code containing a prompt template is the tell.

Business Agents

The judgment workers: each owns a business outcome, performs open-ended work under guardrails, and faces human gates.

ImplementationOne definition file per agent carrying the four-part delegation spec (objective, output format, tools and sources, boundaries); registered in the registry; permissions, evals and gates attach here and only here.

Workflows

Deterministic multi-step business logic on predefined code paths; no open-ended judgment anywhere.

ImplementationPipeline definitions, one per use case where the determination rule says code. A workflow may invoke an agent for one bounded judgment step; pattern P2 is the reference trace.

Copilots

Interactive assistance inside a human's own working session: the human drives, nothing runs unattended, no gates.

ImplementationSame skills and tool servers as agents, different control contract; pattern P4 is the reference trace.

Skills

One use case's procedure and output format, loaded only when that use case runs.

ImplementationSKILL.md per use case with scripts/, references/ and assets/ folders; the only file a new use case adds. Universal rules stay in the constitution.

Domain Rule Library

Deterministic implementations of the rules Knowledge declares: every metric computed once, cited everywhere.

ImplementationExposed to agents as thin compute tools through the south servers; fully unit-tested; it computes, validates, fetches and files, and never decides or drafts.

Subagent Workers

Workers inside one agent's boundary: drafting, citation-checking, red-teaming, fanned out in parallel.

ImplementationDefined inside their parent's definition; report through bounded summary contracts; never face a gate directly; parallelized wherever the dependency graph allows.