LeafEnterprise Backend Implementation Docs¶
LeafEnterprise is Leaf Health's internal-owned backend for PBM savings analysis, claims audits, contract oversight, Salesforce ITR execution, AI optimization, and final client deliverables.
This private site is the formal implementation documentation layer and semantic source of truth for LeafEnterprise backend systems. It is deliberately different from the dated architecture notes under docs/architecture/: those notes preserve decisions and history, while this site explains the current backend systems the engineering team and enterprise agents must operate, extend, index, and defend.
LeafEnterprise is also the backend authority behind scoped client dashboard payloads, including Domo-facing dashboard consumers. Those consumers should receive backend-produced scope, lineage, metrics, evidence status, and deliverable readiness; they should not recreate savings logic or treat Domo as production truth.
System Boundary¶
LeafEnterprise owns the deterministic backend authority for:
| System | Backend authority |
|---|---|
| Savings and audit | report context, queue lineage, workbook generation, final deliverable readiness |
| Salesforce ITR | request mirror, run-plan resolution, evidence bundles, queue handoff |
| Contract guarantees | exact governed contract/pricing/rebate evidence, not Domo-derived pricing truth |
| Agent runtime | task ledger, policy gates, traces, artifacts, tool boundaries |
| Retrieval | packetized evidence, Azure AI Search / Foundry IQ-ready documents |
| AI assistants | Azure OpenAI-backed module copilots with deterministic fallback and evidence disclosure |
Operator Lifecycle¶
The official internal operating loop is:
ITR Workbench -> Agent Workbench -> Savings Audit -> AI Optimization -> final workbook artifact
The lifecycle is intentionally backend-governed. Browser pages can present work and collect operator choices, but the backend owns scope resolution, queueability, evidence sufficiency, calculations, AI grounding, and export readiness.
Documentation Style¶
The structure follows the same intent as formal library documentation such as NVIDIA CUDA-X / CUDA-QX: a collection overview, getting started path, component documentation, examples/runbooks, and API references. For LeafEnterprise, the "libraries" are backend systems rather than GPU packages.
Source Of Truth¶
Use these implementation docs to understand how to call and operate the backend. Use the linked source files and architecture notes when changing behavior:
scripts/serve_client_portal.pyfor the current HTTP route surface.LeafEnterprise/service_contracts.pyfor the first registry of stable endpoint and queue-action contracts.LeafEnterprise/agents/for the internal agent workbench ledger, policy, runner, dispatcher, and SQL guard.LeafEnterprise/salesforce_it_requests/for Salesforce ITR mirror, evidence, materialization, and search-document contracts.LeafEnterprise/contract_guarantees.pyandLeafEnterprise/graph_contract_packets.pyfor strict contract guarantee evidence.
Agent Consumption¶
Enterprise agents and MCP service generators should start with:
llms.txtfor discovery.system-authority/for backend authority, source boundaries, and dashboard ownership.machine/system-authority.jsonfor authority decisions and non-authoritative sources.machine/data-plane.jsonfor source-system roles and allowed consumers.machine/calculation-registry.jsonfor named formulas and blocked states.machine/evidence-lineage.jsonfor source-to-output chains.machine/api-reference.jsonfor structured route metadata.api/routes/for route-family semantics.agent-runtime/mcp-service-contracts.mdfor MCP provisioning rules.
These docs are intended to be deeply semantically indexable. Generated pages carry stable route ids, handler names, route families, source modules, auth posture, field names, response sections, failure semantics, and test anchors.