toga-ai 1.0.972 → 1.0.973

package/knowledge/2.0/apps/worker2/features/talos-pricing-cogs-model.md

@@ -0,0 +1,222 @@
+---
+title: Pricing & COGS Model (Talos Pricing Calculator)
+framework: "2.0"
+repo: worker2
+project: Worker
+client: shared
+type: feature
+status: active
+updated: 2026-10-07
+owners: [jcardinal, akhokhani]
+files:
+  - worker2/Worker/Talos/Pricing.php
+  - tools/_/app/talos/estimator.php
+  - dbchanges2/Team/2026-08-03a - TalosPricingTokenCostModel.sql
+  - dbchanges2/Team/2026-09-17a - TalosInteractionPricingAndContractTerms.sql
+  - dbchanges2/Team/2026-09-17b - RemoveTalosAnnualMaintenanceFee.sql
+related:
+  - ../../../../standalone/apps/talos-backend/architecture.md
+  - ../../../../standalone/apps/talos-backend/features/aegra-api.md
+  - ../../../../standalone/apps/talos-backend/features/observability.md
+  - talos-pricing-automation.md
+  - ../../../../1.0/apps/tools/features/talos-pricing-ui.md
+---
+
+Cost basis + pricing methodology for selling Talos chat and voice; open to re-price Talos or understand COGS drivers, token rates, and the band/org-fee model.
+
+## Summary
+
+Cost drivers, measured production rates, and pricing decisions so anyone can re-price Talos without re-deriving the model.
+
+COGS token economics below remain valid. **The delivery mechanism has pivoted** (2026-06-29) from the per-client Excel workbook (TALOS Pricing Calculator v9) to a **database-backed platform**: a Team-DB system of record + an onboarding/dashboard UI in the **tools** app (1.0) + **worker2** cron automation that calibrates Langfuse usage to AWS actuals each month. Why: Excel can't scale and forced sales to guess inputs (esp. avg conversations/user) they don't know but we already have in Langfuse. See [talos-pricing-ui](../../../../1.0/apps/tools/features/talos-pricing-ui.md) and [talos-pricing-automation](talos-pricing-automation.md).
+
+Treat the numbers as the **April 2026 baseline** (token unit price measured July 2026); re-measure before relying on them later.
+
+## How it works
+
+### Cost methodology — measured token unit price (decision, 2026-08-03) ← CURRENT
+
+**Supersedes the Langfuse calibration-factor method below.** Cost is tokens, priced at the real AWS rate:
+
+```
+unitCostPer1kTokens = AWS Bedrock-family actual $ / measured tokens
+clientMonthlyCost   = client tokens × unitCostPer1kTokens
+```
+
+**Measured July 2026:** $1,013.76 / 258.3M tokens = **$0.00392447 per 1k tokens**.
+
+- **Why not cost-per-conversation.** Measured on True, questions per conversation range **1.0–61.0** (median 2.1, p90 6.5) — a 60× spread. A conversation cannot anchor a price.
+- **Why not usage-API dollars.** The usage API reports cost **~2.5× below** the real AWS bill because it undercounts prompt caching (cache reads are 47% of True's tokens). Its **token counts** are a real measurement and are used; **its dollars never are.**
+- The per-client **calibration factor** is retired.
+
+#### Workload profiles replace the feature checklist (decision, 2026-08-03)
+
+Service offering (CHAT / VOICE_TO_VOICE / NATURAL_VOICE) describes **modality** and says nothing about cost. Cost is driven by tool-call **intensity**, varying by what the client uses Talos for. Measured on True: **42% `mcp_or_other`** (app integrations), **26% `code_interpreter`**, only **19% `knowledge_base`** — the opposite of what was assumed.
+
+Cost per tool call is near flat across categories ($0.046–$0.062; `canvas` the outlier at $0.122), so **a single unit price × an intensity figure** models this and a per-tool price list is unnecessary. Three seeded profiles in `TalosWorkloadProfiles`: **retrieval** / **general** (measured from True) / **analytics** (estimated).
+
+#### Model mix is a bigger lever than any contracted feature
+
+Measured on True: `amazon.nova-pro` serves **70%** of LLM calls at $0.00092/1k while `claude-sonnet-4-5` serves **25%** at $0.00142/1k (76.3% cache). A **routing change moves COGS more than any feature flag**, so `TalosUsageModelMonthly` records model mix per client-month — cheap now, expensive to backfill, and the most likely explanation for a future margin swing.
+
+#### App integrations are recorded but NOT yet priced
+
+`tokensPerIntegrationPerUser` is seeded **0**, `isValidated 0`. Integrations are almost certainly the largest cost driver (`mcp_or_other` = 42% of True's cost), but a slope needs **≥2 clients** with a known integration count and real usage, and there is exactly one. Inventing a coefficient repeats the old $2.00/user default mistake. The plumbing is wired so the estimate, band recommendations, and tool-mix chart all respond the moment a real figure is set. Method recorded in the migration: **regress each client's `mcp_or_other` tokens-per-user against its `appIntegrationCount`.**
+
+#### orgFeeShareOfRevenue (decision, 2026-08-03)
+
+Default **0.25**. Fixes a double-count: the per-user fee was priced to hit the full target margin on its own, so the org-fee recommendation collapsed to ~$0.07 on a $1,036 contract, making the one adjustable lever useless. The seat fee now covers `(1 − share)` of target revenue and the flat fee covers the rest — **effective price per user is identical, only the split changes**. `share = 0` reduces exactly to the old formula. Verified to reconcile to the target margin to the cent.
+
+### Cost methodology — calibrate Langfuse to AWS (2026-06-29) — SUPERSEDED
+
+> Retired 2026-08-03 by the token unit price above. Kept for context on pre-August figures.
+
+Langfuse provides the **structure** (granular per-feature / per-user breakdown); AWS provides the **absolute dollars**. Each month, per client:
+
+```
+calibration_factor = AWS_actual / Langfuse_costCorrected
+```
+
+Apply the factor to Langfuse's granular figures so structure comes from Langfuse, dollars from AWS. New clients (no AWS history) use a **global blended factor** (`SUM(aws) / SUM(langfuse)` across clients) until they have their own rolling 3-month factor. **Langfuse badly undercounts cache cost** (sample: $201 recorded vs $1,088 corrected) — always use the **cache-corrected** Langfuse figure.
+
+### Chat COGS model
+
+Chat AI cost is driven primarily by **LLM tokens on Amazon Bedrock**.
+
+**Bedrock token rates (per 1M tokens):**
+
+| Token class | Rate |
+|---|---|
+| Fresh input | $3.00 |
+| Cached-instruction read | $0.30 |
+| Cache write | $3.75 |
+| Output | $15.00 |
+
+**Measured per-exchange production averages** (tenant DB, April 2026, ~3,610 exchanges):
+
+| Metric | Tokens / exchange |
+|---|---|
+| Cached instructions | 15,013 |
+| Cache write | 2,830 |
+| Output | 527 |
+
+**Per-feature token adders (measured):**
+
+| Feature | Tokens per use | Sample size |
+|---|---|---|
+| Document search | 4,747 / search | 542 searches |
+| Web search | 765 / search | 120 searches |
+| Code execution | 205 / run | 929 runs |
+| App action | 1,086 / action | 71 actions |
+
+**Assumed feature occurrences per conversation:** document search 2, web search 1, code execution 2, app actions 5 **per connected app**.
+
+**Compute and fixed infrastructure:**
+- **Code session compute** — Bedrock AgentCore ~$0.05 / session; ~80% of code-enabled conversations trigger a session.
+- **Platform / hosting** — $910 / month fixed.
+- **Document-search index** — OpenSearch Serverless, +$350 / month, charged **only when Document Search is enabled**.
+
+**Conversation model constants (v8/v9 engine):**
+- System overhead: 200 tokens / conversation
+- Base fresh: 727 tokens / exchange
+- History accumulation factor: ×7
+- Exchanges per conversation: 15
+
+> **Gotcha (flagged for technical review):** history accumulates over ×7 but the per-exchange cost is multiplied by 15 exchanges. This mismatch is a known quirk, **preserved as-is in v9 for number parity with v8** — do not "fix" it silently, as it would change every quoted price.
+
+**Measured cost-per-exchange benchmarks by assistant type (April 2026):**
+
+| Assistant type | Cost / exchange |
+|---|---|
+| Contact Centre | $0.0223 |
+| HR / Compliance | $0.0354 |
+| General Purpose | $0.0435 |
+| Sales / CRM | $0.0829 |
+| Technical / Data-heavy | $0.1139 |
+| Enterprise heavy | $0.1261 |
+
+### Voice COGS model
+
+Talos Voice (voice-to-voice) is priced **per minute**, using the AWS STT/TTS approach. Per-minute drivers:
+
+| Driver | Rate / basis |
+|---|---|
+| LiveKit | $50/mo plan incl. 5,000 min; $0.01/min overage |
+| Amazon Transcribe (STT) | $0.024 / min |
+| Amazon Polly Generative (TTS) | $30 / 1M chars at ~400 chars/min |
+| LLM tokens | ~800 fresh, ~5,000 cached, ~300 output per minute, at the chat token rates above |
+| S3 recording storage | $0.023 / GB-mo at ~0.5 MB/min over the retention window |
+
+### Pricing methodology (decision)
+
+`TalosClients.pricingModel` ENUM(`PER_USER`,`PER_INTERACTION`) selects one of two revenue models. Both share the same COGS basis above, the same **org fee = margin lever**, and the same consecutive-breach smoothing.
+
+**Model A — per-user (default, unchanged):**
+1. **Two-part price.** Client pays a **flat monthly org fee** (the adjustable margin lever) PLUS a **per-user fee that steps by user-count band**.
+2. **Locked band schedule.** The per-user **band rate schedule** is fixed at **contract signing** (`TalosPricingBands`, per-user-model only). When user count crosses a band, the per-user fee auto-steps to the **pre-agreed band rate**; then the **org fee** is adjusted to restore margin. The per-user fee **never changes outside the agreed band schedule**.
+3. **Smoothing rule.** Actual margin is tracked monthly per client. The org fee change is **only recommended after** margin sits outside the min/max band for a configurable number of **consecutive** months (`consecutiveMonths`, per-client; default 3).
+
+> **Pivot note (2026-06-29):** the earlier model used a *fixed* per-user fee + flat fee solved to the band midpoint. The current model makes the per-user fee a **locked band schedule** (steps with headcount) and uses the **org fee** as the margin lever.
+
+#### Model B — per-interaction (decision, 2026-09-17)
+
+For use cases where per-seat makes no sense (many interactions, no fixed user base). An **interaction = one conversation** (`TalosUsageMonthly.conversations`). Output is a **single price per interaction — no volume bands** (`TalosPricingBands` stays per-user-model-only), stored as scalar `perInteractionFee` / `recommendedPerInteractionFee` on `TalosClients`. Cost basis per interaction:
+- **chat:** `tokensPerInteraction / 1000 × unitCostPer1kTokens` (from `TalosWorkloadProfiles.tokensPerInteraction`).
+- **voice:** `avgMinutesPerInteraction × voiceCostPerMinute` (voice-only input; see voice cost factor below).
+
+Revenue = `orgFee + interactions × perInteractionFee`. The org fee is still the monthly lever; the per-interaction rate is locked at signing.
+
+#### Contract-term discount ramp (decision, 2026-09-17)
+
+Fixed 1/3/5-year term dropdown → `contractTermMonths` 12/36/60. A **per-year discount ramp anchored to year 1** (percent always off year-1 price): default Y1 0%, Y2 5%, Y3+ 10%, stored as three editable policy rows `termDiscount.year1/year2/year3plus` in `TalosCostFactors` (the generic Settings page already renders/saves them). Whole-year terms only, **no proration**. Applies to **both** pricing models.
+
+> **Gate (decision):** the ramp applies **only** to contracts that set a term (`contractTermMonths NOT NULL`). Existing no-term clients are unchanged — **no retroactive discount**.
+
+#### Contract fees + amortization (decision, 2026-09-17)
+
+Two **one-time** fees on `TalosClients`: `implementationFee` + `trainingFee`. Amortized to a monthly figure for **display only**:
+```
+amortizedFeeMonthly = (implementationFee + trainingFee) / contractTermMonths
+```
+Guard `contractTermMonths NULL`/0 → `amortizedFeeMonthly` is 0.
+
+#### Two margins: recurring drives, blended displays (decision, CTO review 2026-09-17)
+
+Keep **two** margins separate:
+- **Recurring margin** (`TalosFeeRecommendations` revenue/marginPct) = org fee + ramped usage revenue vs. cost. This **alone** drives the monthly fee-change recommendation and the consecutive-breach streak.
+- **Blended margin** (`amortizedFeeMonthly` + `blendedMarginPct`, new columns) **includes** the amortized fees and is **display-only**.
+
+Why: amortizing one-time fees into the streak input under-fires recommendations mid-term and over-fires an accounting-artifact recommendation at term rollover. The monthly lever for **both** models is the org fee (usage/interaction rate locked at signing); **no new recommendation enum/column** is needed.
+
+### Delivery (current — database platform)
+
+Lives across three repos (schema home + topology in the platform architecture doc):
+- **Team DB (9 `Talos*` tables)** — `TalosClients`, `TalosPricingBands`, `TalosCostFactors`, `TalosUsageMonthly` + `TalosUsageFeatureMonthly`, `TalosAwsActualsMonthly`, `TalosClientUserCounts`, `TalosCalibrationMonthly`, `TalosFeeRecommendations`. (`dbchanges2/Team/...TalosPricingTables.sql`)
+- **tools app (1.0)** — onboarding (locks the band schedule), pricing dashboard, usage benchmarks, technical-only Cost Factors editor + `App_Talos_Estimator`.
+- **worker2 (2.0)** — monthly crons: import AWS actuals, recompute calibration + margins/recommendations, send leadership report.
+
+The previous **TALOS Pricing Calculator v9** Excel workbook (Sales / Voice / Technical / Actuals / Engine tabs, per-client file under the shared AI drive) is **superseded** by this platform but documents the same economics.
+
+## Gotchas
+
+- **Numbers are an April 2026 baseline.** Token rates, AWS prices, and measured per-exchange averages drift — re-measure from the tenant DB before quoting later.
+- **History ×7 vs. ×15 exchanges quirk** (see Chat model) — intentional parity hack, not a bug to silently correct.
+- **OpenSearch +$350/mo is conditional** — only counts when Document Search is enabled; do not bake it into every quote.
+- **Voice cost is per-minute, not a token multiplier.** For **per-interaction voice**, cost = `avgMinutesPerInteraction × voiceCostPerMinute` — a new `TalosCostFactors` policy row (seeded **0.055**, `isValidated=0` UNMEASURED, built from AWS published per-minute rates). This **replaces** the old 0.25 / 0.50 modality multipliers for voice. Chat still uses the token basis.
+- **Voice multipliers 0.25 / 0.50 are UNVALIDATED** — supplied second-hand, never measured, and may be **inverted**. Flagged in the UI. Do not quote voice from them. (Superseded by `voiceCostPerMinute` for per-interaction voice.)
+- **Pricing math is duplicated across two frameworks — guard drift.** `App_Talos_Estimator` (1.0, tools) and `_Worker_Talos_Pricing` (2.0, worker2) cannot share PHP, so every constant lives in Team-DB `TalosCostFactors` policy rows that **both** read, and a golden-master **parity test** locks them together (fixture `test/talos/pricing-parity-fixture.json` + a CLI test per repo that reflection-seeds the settings cache and calls the real methods: `tools/_/app/talos/estimator.parity.test.php`, `worker2/Worker/Talos/PricingParityTest.php`; 11/11 pass both). Never hardcode a pricing constant in one class. **Open:** extract the worker's composed `RecomputeMargins` margin formula into its own callable so parity can assert it directly; `marginPct` 0-vs-null on zero-revenue differs between the two classes (pre-existing).
+- **`infraFixedMonthly` is 0** — shared platform cost has never been measured, so band recommendations come out flat. That flat table is the **honest output, not a bug**.
+- **Internal tenants are costed but not quoted** — True (TOGA Technology) feeds the platform unit price and is excluded from fee recommendations; see `talos-pricing-automation`.
+- **Do not embed the absolute drive path as canonical** — the calculator lives under the team shared AI drive; the path can move.
+
+## Change history
+- 2026-10-07 — moved to 2.0/worker2 (framework axis per CONVENTIONS) (akhokhani)
+- 2026-09-25 — renamed product references/frontmatter project from "TOGa IQ" to "TOGa Talos" (rebrand; TOGa IQ is now the separate `toga25-iq` app) (jcardinal)
+
+## Related
+
+- [../architecture.md](../../../../standalone/apps/talos-backend/architecture.md)
+- [aegra-api.md](../../../../standalone/apps/talos-backend/features/aegra-api.md)
+- [observability.md](../../../../standalone/apps/talos-backend/features/observability.md)
+- [../../worker2/features/talos-pricing-automation.md](talos-pricing-automation.md)
+- [../../../1.0/apps/tools/features/talos-pricing-ui.md](../../../../1.0/apps/tools/features/talos-pricing-ui.md)

package/knowledge/clients/compass-usa/features/talos-supply-assistant.md

@@ -0,0 +1,67 @@
+---
+title: Compass USA Talos Supply Assistant
+framework: "standalone"
+repo: talos-backend
+project: TOGa Talos
+client: compass-usa
+type: client-feature
+status: active
+updated: 2026-10-08
+owners: [akhokhani]
+files:
+  - talos-backend/deployments/tenants/compass-usa/manifest.json
+  - talos-backend/deployments/tenants/compass-usa/persona.txt
+  - talos-backend/deployments/tenants/compass-usa/toga-supply.blp
+  - talos-backend/deployments/tenants/compass-usa/candidates/2026-10-07/instruction-publication.json
+  - talos-backend/mcp-servers/toga-platform-mcp/src/toga_platform_mcp/tools/supply/view_query.py
+related:
+  - ../profile.md
+  - ../../../standalone/apps/talos-backend/workflows/toga-supply-client-onboarding.md
+  - ../../../standalone/apps/talos-backend/features/toga-platform-mcp.md
+  - ../../../2.0/apps/toga25-supply/features/talos-integration.md
+  - ../../../standalone/apps/talos-backend/features/tenant-configuration.md
+---
+
+Compass USA's Talos assistant answers read-only Supply questions under the user's api2 permissions; open for tenant identity, published instruction evidence and launch checks.
+
+## Summary
+
+Canonical org is `Compass_Usa`, external slug/name `Compass Group`, database `tenant_compass_usa`. Assistant `toga-supply` (“TOGa Supply”) uses the shared `deep_agent`, not a client-specific graph. This page owns Compass differences; shared wiring and provisioning live in the linked Supply/MCP docs.
+
+## How it works
+
+The saved production survey **as of 2026-10-07** found assistant `9d4b80d2-e592-5e75-bd0d-c09994d93e56` at version 8 with Sonnet 5 caching. Customer-facing/read-only metadata was set. Limits were 32k context, recursion 32, 12 model calls/run, 120/thread and 24 tool calls/run. Plan/HITL/CI/artifacts/skills/writing blocks/tool routing were off at assistant level; spend governance and BLP config were on.
+
+Persona `toga-supply` had the same stored instruction length as legacy assistant `persona_prompt`, an embedding, orchestration off, category `blp`, domain TOGa Supply Operations and MCP `toga-platform`. Its exact native tool junction contained only `query_business_logic`; catalog MCP link contained only user-bearer toga-platform. There were no KB/skill/starter assignments. Shared platform MCP selects Supply versus Commerce from authenticated request context; adding an enabled catalog row alone is not the customer's authorized tool set.
+
+The October 7 candidate/publication record stored assistant v8, BLP **1.3.0 with 12 blocks**, 1024-dimensional embedding, preserved settings/assignments and successful DB readback. It explicitly recorded **`live_answer_tested:false`**. Persona/BLP publication and MCP code deployment are independent: local `view_query.py` grounds UI questions in authorized views, but the saved research did not identify the deployed MCP source SHA.
+
+### Customer answer rules
+
+Use customer terminology Kit/Bundle, authorized UI status stages from Pending Initial Approval through Fulfilled, and short read-only answers. Omit vendor/purchasing internals from customer responses. UI links follow the actual TableView filter contract: `/sales-orders?sales-orders=...`, `/items?items=...`, `/bundles?bundles=...`. Do not substitute raw API fields for UI filter/status semantics. Compass Canada is outside this tenant's scope.
+
+### Launch evidence and open gates
+
+Production backend instructions were read back and the survey counted 73 successful runs over its preceding 30 days. This proves backend use, not a launched Supply panel. Production Core/Client Surface grants were not inspected, and the handoff explicitly did not change panel enablement or access grants. Validate the intended non-admin user's `talos-assistant` bundle and active `/users/me` slug entitlement before calling launch complete.
+
+Supply's inspected production provider still lacked wired server cancellation, persisted transcript reload and run-ID rejoin. These cross-app gates remain in [Supply integration](../../../2.0/apps/toga25-supply/features/talos-integration.md).
+
+## Gotchas
+
+- Tenant `feature_flags.blp=false` conflicts with assistant BLP/junction configuration. Assembly checks both; no `query_business_logic` calls were observed in the survey's last 30 days. Treat BLP execution as needing a runtime check.
+- Tenant `mcp=false` did not prevent observed platform tool calls. A boolean catalog/flag audit cannot replace per-run context and business ACL verification.
+- Enabled static-key ClickUp/toga-db catalog rows were present but unbound to this customer assistant. Review their tenant visibility before exposing another persona.
+- `model_defaults.summarization=sonnet-4-5` was absent from its AIP registry; assistant Haiku 4.5 masked that fallback problem. Effective config, not a single row, determines behavior.
+- Instruction publication does not certify deployed MCP source, customer access or answer quality. Keep all three evidence records separate.
+
+## Related
+
+- [profile](../profile.md)
+- [toga supply client onboarding](../../../standalone/apps/talos-backend/workflows/toga-supply-client-onboarding.md)
+- [toga platform mcp](../../../standalone/apps/talos-backend/features/toga-platform-mcp.md)
+- [talos integration](../../../2.0/apps/toga25-supply/features/talos-integration.md)
+- [tenant configuration](../../../standalone/apps/talos-backend/features/tenant-configuration.md)
+
+## Change history
+
+- 2026-10-08 — Reconciled local source and dated 2026-10-07 research into the canonical KB (akhokhani).

package/knowledge/clients/tow-foundation/features/talos-tenant.md

@@ -0,0 +1,59 @@
+---
+title: Tow Foundation Talos Tenant
+framework: "standalone"
+repo: talos-backend
+project: TOGa Talos
+client: tow-foundation
+type: client-feature
+status: active
+updated: 2026-10-08
+owners: [akhokhani]
+files:
+  - talos-backend/libs/aegra-api/src/aegra_api/core/control_plane_orm.py
+  - talos-backend/libs/aegra-api/src/aegra_api/services/context_assembler.py
+  - talos-backend/libs/aegra-api/src/aegra_api/services/assistant_config_service.py
+related:
+  - ../profile.md
+  - receipt-processing.md
+  - ../../../standalone/apps/talos-backend/features/tenant-configuration.md
+  - ../../../standalone/apps/talos-backend/features/ai-service-endpoints.md
+  - ../../../standalone/apps/talos-backend/features/mcp-servers.md
+---
+
+Tow Foundation has a separate Talos tenant with legacy assistant configuration; open for exact org casing, dated resource boundaries and activation risks.
+
+## Summary
+
+The read-only production survey **as of 2026-10-07** found canonical org ID **`Towfoundation`** (lowercase f) and database `tenant_towfoundation`. Older notes spelling `TowFoundation` are not the surveyed control-plane identity. Verify the real JWT/client registration when changing any mapping; do not compensate with fuzzy runtime matching.
+
+## How it works
+
+Eight configured assistants used `deep_agent`: legacy `talos` plus legal, executive, contact-center, hr, operations, sales and dev-core persona assistants. There was also the system placeholder. All eight `model_preset_id` values were NULL despite `default` Sonnet 5 and `fast` presets existing; runtime falls through its configuration cascade rather than acquiring the preset by name alone.
+
+Persona assistants had recursion 25 and SANDBOX CI network. Legacy `talos` had recursion 150, PUBLIC CI, a long legacy `persona_prompt`, and plan/HITL/skills disabled. Seven persona rows had orchestration off and relatively short prompts. Persona junctions had 14–15 tools and eight skills each; legacy Talos had nine tools and no skills.
+
+The tenant had no KBs, legacy MCP rows, API keys, Composio records or crons. Static-key catalog `clickup` and `toga-db` were healthy; Dev Core's persona referenced toga-db, Sales/Executive referenced both. The BLPs were older TOGA-oriented Sales Forecast & Actuals, Sales Opportunity Pipeline, Office Depot Order Research and an unbound Compass Order Checking. Sales/Executive each bound two; Dev Core/Operations bound Office Depot Order Research.
+
+Tenant flags enabled BLP/canvas/CI/plan/summarization/thread naming/tool routing but disabled `mcp`. Reminders and Composio flags were absent. Tenant env-mode was LOCAL. KB full-document expansion was enabled, unlike other surveyed tenants; with no KB assignments this did not prove retrieval activity. System prompt v10 dated April 20 was active.
+
+All-time activity was 15 threads/51 runs/two users, entirely on legacy `talos`; none occurred in the survey's preceding 30 days, with last run August 26. These are historical aggregates, not a statement that the client is currently inactive.
+
+## Gotchas
+
+- The TOGA database/ClickUp catalog and TOGA-internal BLP content create a potential cross-client exposure if these persona assistants are activated. Review data authorization and resource ownership before enabling; no activation is authorized by this documentation migration.
+- NULL preset IDs, small recursion limits and disabled MCP are separate configuration issues. Do not copy True tenant defaults as a repair.
+- A static-key catalog health result proves shared connectivity, not user-specific entitlement or client-safe data scope.
+- Current model resolution and schema readiness must be checked via the shared tenant/deployment workflows; the saved survey is dated evidence.
+- Tow's receipt-extraction worker uses the separate structured AI-service endpoint; it is not proof that these interactive assistants were used.
+
+## Related
+
+- [profile](../profile.md)
+- [receipt processing](receipt-processing.md)
+- [tenant configuration](../../../standalone/apps/talos-backend/features/tenant-configuration.md)
+- [ai service endpoints](../../../standalone/apps/talos-backend/features/ai-service-endpoints.md)
+- [mcp servers](../../../standalone/apps/talos-backend/features/mcp-servers.md)
+
+## Change history
+
+- 2026-10-08 — Reconciled local source and dated 2026-10-07 research into the canonical KB (akhokhani).

package/knowledge/clients/true/features/talos-internal-tenant.md

@@ -0,0 +1,72 @@
+---
+title: TOGA Technology Internal Talos Tenant
+framework: "standalone"
+repo: talos-backend
+project: TOGa Talos
+client: true
+type: client-feature
+status: active
+updated: 2026-10-08
+owners: [akhokhani]
+files:
+  - talos-backend/libs/aegra-api/src/aegra_api/services/context_assembler.py
+  - talos-backend/libs/aegra-api/src/aegra_api/services/assistant_config_service.py
+  - talos-backend/libs/aegra-api/src/aegra_api/core/control_plane_orm.py
+  - talos-backend/libs/aegra-api/src/aegra_api/core/orm.py
+related:
+  - ../profile.md
+  - ../../../standalone/apps/talos-backend/features/tenant-configuration.md
+  - ../../../standalone/apps/talos-backend/features/composio-integrations.md
+  - ../../../standalone/apps/talos-backend/features/knowledge-base-search.md
+  - toga-hd-voice-demo.md
+---
+
+The internal True tenant hosts TOGA's Talos assistants and shared agent resources; open for its exact identity, dated assignments and configuration discrepancies.
+
+## Summary
+
+Canonical org ID is case-sensitive `True`, with tenant database `tenant_true`. This page records the saved read-only production survey **as of 2026-10-07**, not a new DB check. Generic configuration precedence, assignments and inspection rules live in [tenant configuration](../../../standalone/apps/talos-backend/features/tenant-configuration.md).
+
+## How it works
+
+Nine configured assistants use `deep_agent`: hr, dev-core, sales, contact-center, operations, legal, executive, one and sales-demo. A separate unconfigured `deep_agent` row is the system placeholder. All configured assistants selected the default Sonnet 5 Bedrock preset with prompt caching; auxiliary models were Haiku 4.5 summarization and Nova Micro thread naming. Eight persona rows existed; `one` had no persona row. Dev Core, Executive and Sales allowed orchestration; the others did not. No persona embeddings were stored in that survey.
+
+Common assistant settings were 400k context, recursion 100, balanced HITL, skills/plan/artifacts/CI/spend governance/writing blocks. Model-call limits were 100/run on Dev Core/Executive/Sales and 50 elsewhere, tool limit 200/run. PUBLIC CI network was assigned to Dev Core/Executive/One/Sales/Sales Demo; HR/Legal/Operations/Contact Center used SANDBOX. These assignments are evidence, not authority to enable PUBLIC for another assistant.
+
+### Resource assignments
+
+- Dev Core had 32 bound KBs; Sales and Executive shared `4ETAEXIGCU`. HR, Legal, Contact Center and Operations each had a specialist KB. One and Sales Demo had none. Of 39 total KBs, three were unbound, including `executive-toga-technology` (`GWIYZLSZP4`).
+- Every persona assistant bound the eight system skills except Sales Demo lacked internal-comms. `_shared` stored common resources.
+- Executive had four BLPs: Executive Operating and Revenue Review 1.6.2, NetSuite Business Operations 1.3.4, Sales and Opportunity Intelligence 1.4.0, Strategic Account Review 1.9.1. Sales bound the latter three; Dev Core bound Efficient Database Research 1.0.0.
+- Operations declared the Office Depot Order Research domain and enabled BLP in config, but had no `assistant_blp_files` junction. That BLP and Compass Order Checking were unbound.
+- Catalog `clickup` and `toga-db` were healthy static-key entries, reachable through persona MCP slugs; no normalized assistant catalog-link rows existed. Executive also retained two legacy MCP assignments. Catalog and legacy tables are different assignment paths.
+
+### Settings and operational activity
+
+`bedrock_profiles` was schema v2 under key `True`, with only a production environment block. `assistant_defaults.recursion_limit=25` differed from per-assistant 100 and matters only as fallback. Tenant `environment.env_mode=DEVELOPMENT` differed from local `.env.prod` process `ENV_MODE=PRODUCTION`; security code reading the tenant namespace must be inspected independently.
+
+Active system prompt was v16 while newer v22 was inactive; several CI/canvas/plan/thread-name templates similarly had newer inactive versions. “Latest” is not “active.” Memory capture/profile/episode flags were absent, so current code defaults determine behavior rather than an explicit tenant opt-in.
+
+Composio policies included active default-composio on One, canary Executive NetSuite read and Sales connected apps, plus an orphaned Sales NetSuite predecessor with active subject bindings. The survey counted 23 connections, including 11 NetSuite INITIATED, and 68 approved versus 182 pending-review actions. Presence in the catalog does not grant execution.
+
+The survey counted 11 API keys (9 active), 14 crons (5 enabled), 2,220 runs and 82 distinct users over its preceding 30 days. Scope-specific integrations included `usage:read`, `usage:read:all` and `campaign:manage`; do not copy key values or end-user identities into knowledge.
+
+## Gotchas
+
+- Missing Executive KB binding and missing Operations BLP junction contradict older memory assumptions. Inspect assignments instead of adding IDs only to persona text.
+- Tenant env-mode, process environment and profile environment are distinct. None should be inferred from another.
+- Prompt versions can exist without being active; selection and cached runtime context must be checked.
+- The dated survey found all tenant schemas at `schedule_result_email_v1`, behind the then-local head. [Deployment](../../../standalone/apps/talos-backend/features/deployment.md) owns migration/release ordering; do not advance schema ahead of an image without its contract.
+- This tenant also pays for cascaded ODP/demo voice AIPs. That billing identity does not turn Office Depot into a separate Talos PostgreSQL org.
+
+## Related
+
+- [profile](../profile.md)
+- [tenant configuration](../../../standalone/apps/talos-backend/features/tenant-configuration.md)
+- [composio integrations](../../../standalone/apps/talos-backend/features/composio-integrations.md)
+- [knowledge base search](../../../standalone/apps/talos-backend/features/knowledge-base-search.md)
+- [toga hd voice demo](toga-hd-voice-demo.md)
+
+## Change history
+
+- 2026-10-08 — Reconciled local source and dated 2026-10-07 research into the canonical KB (akhokhani).

package/knowledge/clients/true/features/toga-hd-voice-demo.md

@@ -0,0 +1,62 @@
+---
+title: TOGA Help Desk Voice Demo
+framework: "standalone"
+repo: voice-to-voice
+project: TOGa Voice
+client: true
+type: client-feature
+status: active
+updated: 2026-10-08
+owners: [akhokhani]
+files:
+  - talos-backend/voice-to-voice/clients/toga-hd/agent.py
+  - talos-backend/voice-to-voice/clients/toga-hd/config.yaml
+  - talos-backend/voice-to-voice/clients/toga-hd/agents/tech_support.py
+  - talos-backend/voice-to-voice/clients/toga-hd/deploy.sh
+  - talos-backend/voice-to-voice/clients/toga-hd/livekit.toml
+related:
+  - ../profile.md
+  - ../../../standalone/apps/voice-to-voice/architecture.md
+  - ../../../standalone/apps/voice-to-voice/features/ticket-api-integration.md
+  - ../../../standalone/apps/talos-backend/features/realtime-voice-and-dictation.md
+---
+
+The TOGA Help Desk demo compares cascaded and native speech-to-speech calls with simulated tickets; open before changing its mode, deploying to the shared slot, or connecting real Desk credentials.
+
+## Summary
+
+`voice-to-voice/clients/toga-hd/` is TOGA Technology's internal demo, using tenant `True` and S3 prefix `toga-hd/upload`. It shares the ODP test agent slot `CA_7EHEBwQxsDbA` in LiveKit project `talos-prod`. The saved 2026-10-07 audit observed it running after a redeploy, but did not verify the deployed source revision or active voice mode. The local mode implementation and shared config changes were uncommitted at that time.
+
+## How it works
+
+`VOICE_MODE` env overrides YAML `voice_mode` (default `robotic`), selected at worker startup. `deploy.sh --mode natural|robotic` updates the secret and deployment; there is no separate production target for this demo.
+
+| Mode | Local implementation |
+|---|---|
+| robotic | Transcribe fallback → tenant True Haiku 4.5/Sonnet 4.5 AIPs → Polly Matthew; 300 output tokens, preemptive TTS, endpointing 0.5–0.8 seconds |
+| natural | AWS realtime plugin with `amazon.nova-2-5-sonic`, Matthew voice, MEDIUM turn detection, temperature 0.7/top-p 0.9, 1024 tokens, mixed modalities and 15-second generate-reply timeout |
+
+The natural fallback model is `amazon.nova-2-sonic-v1:0`. Canonical IDs are required because the saved bidirectional canary rejected AIPs; natural-mode spend therefore lacks the cascade's tenant AIP attribution. This exception does not authorize canonical fallback in Talos production web voice. MEDIUM replaced HIGH because HIGH spoke tool-call text in the recorded benchmark. The plugin recycles below its eight-minute provider connection limit.
+
+Only `create_support_ticket` and `end_call` are exposed. The demo has no KB search tool: the available demo KB held ODP procedures, and natural-mode tool round trips introduce dead air. `simulate_tickets: true` yields a fake six-digit ticket number and makes no real Ticket API reads or writes.
+
+Real tickets require a pair bound to Demo client 188/department 348. The saved setup record says that pair was pending. ODP's client 3/department 322 pair must never be substituted. The agent writes demo artifacts to S3; as of 2026-10-07 Lambda `CLIENT_IDS=odp` and no `TOGA_HD_*` credentials meant demo uploads were not processed.
+
+## Gotchas
+
+- ODP's default deploy replaces this demo. Inspect the selected LiveKit config/agent ID before a test deploy.
+- YAML dispatch name is overridden by the demo deploy script's `AGENT_NAME=tech-support` to match the shared dispatch. Changing only YAML cannot retarget the phone route.
+- The local README advertises `--with-oneuptime`, but the inspected deploy script rejects it. Toga-hd startup does not contain ODP's supervised heartbeat loop.
+- Natural-mode code presence and a recent agent timestamp do not identify the live build/mode. Read current deploy metadata and non-secret mode configuration when authorized.
+- Do not disable simulation or add demo Lambda credentials until Desk routing is verified end to end.
+
+## Related
+
+- [profile](../profile.md)
+- [architecture](../../../standalone/apps/voice-to-voice/architecture.md)
+- [ticket api integration](../../../standalone/apps/voice-to-voice/features/ticket-api-integration.md)
+- [realtime voice and dictation](../../../standalone/apps/talos-backend/features/realtime-voice-and-dictation.md)
+
+## Change history
+
+- 2026-10-08 — Reconciled local source and dated 2026-10-07 research into the canonical KB (akhokhani).

package/knowledge/standalone/apps/ai-bdr/INDEX.md

@@ -0,0 +1,9 @@
+# ai-bdr (AI-BDR) — standalone knowledge
+
+| Doc | Summary |
+|-----|---------|
+| [AI-BDR Architecture](architecture.md) | How TOGA's outbound AI SDR fits together; open when working anywhere across the Vapi side, the PHP worker orchestration, or the web funnel front door. |
+| [Call Orchestration — PHP Worker ↔ Vapi (the integration seam)](features/call-orchestration.md) | Exact wire shape of the three PHP-worker ↔ Vapi integration points; open when building or debugging the outbound call, the end-of-call webhook, or the inbound c |
+| [Vapi Integration — Assistants, Tools, Structured Output](features/vapi-integration.md) | Everything inside Vapi — assistants, tools, shared structured-output schema, Liquid prompt, and the Python scripts that author them; open when changing assistan |
+| [New-Campaign Onboarding (6-phase runbook)](workflows/new-campaign-onboarding.md) | End-to-end procedure to launch a new outbound BDR campaign; open when standing up a campaign across marketing, backend, Vapi, and Cal.com. |
+| [Safe AI-BDR Call-Loop Testing (isolated test-campaign runbook)](workflows/safe-call-loop-testing.md) | How to prove the AI-BDR dialer→Vapi→webhook loop end-to-end without dialing real prospects; open before any live-campaign test. |