Two servers.
One consistent
customer experience.

A complete plan, not a production claim

The goal remains a useful, natural customer conversation anchored to a verified customer, the selected circuit, approved company knowledge and time-stamped operational evidence. The assistant must expose uncertainty, enforce scope, and hand off whenever the facts or authority are insufficient.

This independent public review covers evidence from 23 October through 3 November 2026. Engineering authority remains the ADN AI System Management v15 master pointer and its dated v16 research/delivery checkpoints. This public edition is not an accepted engineering master-plan version and does not claim complete access to the final v16 attachment or live ChatGPT conversations.

New records since the October 30 candidate include locally tested service-identification contracts, a partial customer-context source-sizing exercise, a private WhatsApp archive-index candidate, and continuing Index 9 monitoring. These are different evidence stages. No new customer production rollout, installed second GPU, failover, or benchmark acceptance is established by this documentation review.

The platform, end to end

Incoming WhatsApp and contact-center events enter a durable queue. A verified identity and service-selection layer establishes the account, selected DAT, company and permitted sources. The router chooses a bounded workflow; retrieval adapters assemble a time-stamped evidence package; the local model produces a proposed answer; validators and delivery controls determine whether it may be shown or sent.

Keep the responsibilities separate: finding an account is not authenticating the caller; authenticating the caller is not granting financial access; producing valid JSON is not proving a fact; and generating a reply is not permission to deliver it. The customer path must not inherit unrestricted staff-search access.

Brain is the primary conversational host in the initial target design. ADN-RAG performs retrieval and background knowledge work and is being prepared to support independent inference and failover. Public website publishing remains outside the customer-serving system.

Two RTX 5090s. Two independent computers.

The owner-approved direction is one RTX 5090 in Brain and one RTX 5090 in ADN-RAG—not two cards in one machine. The target is 64 GB of system RAM per host. The RAG upgrade also targets a 4 TB NVMe data drive and a separate boot drive; the boot capacity and final installation evidence still need confirmation.

A dated October 30 host observation identifies the 5090 in Brain. The second card is recorded as ordered, not installation-accepted. Engineering correspondence identifies power-supply and compatible-memory work still to be completed. Confirm chassis clearance, slot fit, connectors, cooling, power and runtime compatibility against the actual board and host before installation.

Each RTX 5090 has 32 GB of GPU memory [N1]. System RAM and GPU memory are different budgets. Two independent 32 GB GPUs do not become one transparent 64 GB pool. For independent survival, each host must be able to load its complete required model and execute the minimum customer workflow without the other host.

Pin the model artifact and hash, quantization, tokenizer, chat template, inference runtime, prompt, tool schema and context limits. Keep a compatible deployment package on both nodes. A second GPU alone does not replicate queues, authentication, databases, outbound delivery or source permissions.

Availability before load sharing

Phase A is primary plus warm standby: Brain handles customer inference; ADN-RAG maintains a ready, compatible inference stack while running its own jobs within measured resource limits. Phase B is controlled active-active inference, considered only after a single surviving node has passed the acceptance workload. These are different modes, not two names for a completed installation.

Choose explicitly between full coexistence and degraded operation. Full coexistence means the surviving node handles the complete agreed customer workload while required RAG/GPU jobs continue. Degraded mode may pause or throttle nonessential indexing, embeddings and document processing to protect customer replies. Passing degraded mode must not be reported as passing full coexistence.

The working target is approximately 20 customer conversations, with 25 as an additional stress scenario where approved. Open conversations are not simultaneous model generations. Measure active requests, context length, output length, tool time, queue delay and the exact mix of foreground and background work. No capacity guarantee is inferred from the card specification.

The customer conversation contract

Start from a trusted channel or contact-center validation, then resolve the account and specific service. A telephone match or Index 9 discovery is a clue, not authentication. DAT identifies a circuit, not the customer: a customer may own multiple DATs. A separately named customer identifier has been proposed, but migration and production acceptance are not demonstrated.

The November 1 identification API v2 candidate adds locally tested DAT-family matching, ambiguity handling and paginated service discovery. Existing hosted v1 and Odoo checks were recorded separately. The full hosted v2 test series is still blocked on an authorized staging source and route; local assertions cannot be promoted to production acceptance.

Core intents remain technical support, financial/billing (including disconnection), and additional services. Maintain natural Costa Rican Spanish, English and mixed-language turns. Clarify only when a safe next action requires it; do not turn customer assertions into verified payment or network facts.

Persist minimal durable state: authenticated principal, service scope, grant revision, turns, pending tools, evidence references, escalation and delivery IDs. A second host must reconstruct it without trusting stale GPU key/value cache or another customer’s session.

A validated result contract separates findings, hypotheses, missing evidence, proposed checks, approval requirements, customer-facing language and human handoff. A generated reply is not permission to send messages, change the network or modify financial records.

One canonical evidence package in RAM

For a trusted, currently authorized session, assemble network and financial contexts separately. The selected DAT and verified account scope govern retrieval. Large attachments, manuals and telemetry histories stay in durable approved stores; the model receives only relevant bounded excerpts and citations.

Use a canonical, source-attributed snapshot with schema version, snapshot hash, capture time, account/service grant revision, relevant conversation turns, source watermarks, measured units, confirmed dependencies, source freshness, conflicts and completeness flags. No adapter should silently substitute an old mirror for live financial or monitoring truth.

Paired experiments must freeze identical approved, minimized substantive evidence and dialogue for Gemma and exactly one verified, pinned cloud model. Native tokenization may differ; keep a common input hash, result schema and expert adjudication. A cloud answer is not the ground-truth label.

The earlier 2 GiB process ceiling, 1.75 GiB entry budget and five-minute inactivity policy belong to a synthetic cache candidate, not a measured production allocation. An October 31 bounded source-sizing exercise measured selected records for 20 and 50 accounts, with incomplete monitoring and accounting coverage; payload serialization is not cache resident memory, concurrency capacity or complete customer context.

An authorized foreground read may renew the proposed five-minute idle timer subject to the grant’s absolute expiry. Renewal must not imply fresher source data or revive a revoked grant. Cache keys must include tenant, identity/scope and permission epoch; invalidate on reassignment, revocation or account change and preserve an explicit partial/stale state.

Illustrative contract — synthetic identifiers only

{
  "schema_version": "candidate-v1",
  "snapshot_id": "synthetic-example",
  "scope": {
    "account": "ACCOUNT-A",
    "service": "CIRCUIT-A",
    "session_revision": 3
  },
  "sources": [
    {
      "evidence_id": "E-01",
      "observed_at": "2026-10-30T18:00:00-06:00",
      "status": "reviewed"
    }
  ],
  "conversation": [
    {
      "role": "customer",
      "text": "My internet connection stopped working."
    }
  ],
  "complete": false,
  "missing_sources": [
    "current upstream observation"
  ],
  "comparison": {
    "input_hash": "computed from frozen bytes",
    "models": [
      "Gemma",
      "one pinned OpenAI model"
    ]
  }
}

Validate conversations and their supporting data

Judge the final customer conversation: was the account and circuit correct, evidence recent and allowed, uncertainty honest, and the next step useful? Index integrity and valid JSON support this goal but do not establish real-world answer quality.

For every source adapter, name its authoritative field owner and reconcile original, collected, permitted, indexed and retrieved records, deletions, account-to-service relationships and complete pagination. Source errors and unknown mappings must remain visible, not be interpreted as no outage or no outstanding balance.

Index 9 has a dated test-environment installation and repeatable local refresh checks. A November 3 check reported clean local state but could not verify live HTTP health or upstream freshness. A failed monitoring connection is not proof of a service outage; an active timer is not end-to-end customer verification.

A November 2 owner-private WhatsApp-only index candidate reconciled archive records, eligibility, chunk membership and index integrity. It was not activated for customer answers. Archive freshness, sensitive-data coverage, independent semantic accuracy and account-scoped access are still unverified. Email archive, WhatsApp text index and customer-facing semantic retrieval must remain separate until proven together.

For shared fiber incidents, map the selected service to verified common dependencies and current telemetry; do not infer causation from nearby device names. Keep fiber and wireless backup context distinct, and preserve conflicts in the customer-facing diagnostic assessment.

Eight knowledge domains, plus service discovery

The inherited architecture separates eight knowledge domains and the additional Index 9 discovery function. Use the owning project’s canonical catalog for numeric mappings; do not renumber indexes from a generic diagram. Access policy applies to every domain, not only questions about permissions.

Gemma versus one OpenAI reference model

Use one selected cloud reference in each experiment. This edition centers the requested Gemma-versus-OpenAI comparison; earlier notes retain Claude as an alternative, not a second mandatory comparator or a three-model vote. Pin the exact available API model before the run rather than describing the reference as “whatever ChatGPT is today.” No paid model comparison was executed to produce this page.

Shadow evaluation and live fallback are separate workflows. In shadow mode, both models answer the frozen case independently and neither automatically sends to the customer. In live fallback, an approved policy may request help for a specific answer, subject to scope, latency, cost and human-escalation rules. Cloud access cannot repair unavailable source data or missing customer authorization.

Create a paired-case record with the same snapshot hash, question, conversation turns, task instructions, allowed tool policy and output schema. Save model/runtime versions, prompt version, decoding settings, truncation decisions, raw output, validated output, errors, latency, token usage and cost. Neither model sees the other answer before scoring.

Compare the answers against independent, verified outcomes and expert-reviewed labels—not against the OpenAI answer simply because it came from a larger model. Randomize answer order for blind human review, separate factual correctness from presentation, and calibrate any automated judge against expert labels. Preserve disagreements and failed cases [O1].

Cloud transfer is a distinct approval gate. Build an allowlisted, minimized evidence projection and replace identifying values consistently where possible. Exclude secrets and unnecessary customer, financial or communications data. Do not send a private conversation or training corpus merely because this public planning page has been approved.

Measure the conversation, not just the JSON

Build representative, permission-reviewed case families for outages, billing questions, disconnections, add-ons, multiple services, unknown identity, unavailable sources and escalation. Include Costa Rican expressions, incomplete messages, ambiguity, long exchanges and conflicting observations. Split by customer/incident family and time to avoid putting copies of one conversation in both development and test.

Use three separate evaluation tracks. Interpretation and routing tests ask whether the right intent and service were selected. Retrieval tests ask whether authorized, relevant and sufficiently fresh evidence was found. Answer-and-delivery tests ask whether claims are supported, the next step is safe, the conversation remains coherent and duplicate or unapproved sends are prevented.

Existing records are useful baselines, not interchangeable scores: the October 23 local-model comparison used 60 frozen cases and three repeated trials at concurrency one; the October 29 customer-context candidate recorded 20 synthetic workflow tests; the email pilot records 48 cases and 12 focused checks. Repeated trials do not multiply the number of independent examples, and none establishes 20 simultaneous customer sessions.

Before a release, freeze the rubric and pass/fail gates. Track correctness, unsupported claims, citation validity, account/service isolation, clarification quality, unnecessary questions, handoff appropriateness, task completion, p50/p95 latency and cost. Treat unauthorized disclosure or unsafe action as a blocking failure, not something averaged away by a high score.

Record failures as well as passes. A previously passing component suite cannot override a later failed concurrency or recovery check. Publish sample size, test date, model and environment, and whether labels were human-reviewed. Set operational thresholds with the owners before load testing; this page does not claim those thresholds have been met.

Improve knowledge, orchestration and weights separately

First diagnose the failure. Missing or stale evidence belongs in ingestion, mappings and retrieval. Wrong tool selection or confusing phrasing belongs in routing and prompts. Repeated behavior failures that remain after those fixes may justify a separate tuning experiment. Do not retrain the model to memorize changing balances, device state or permissions.

Promote a resolved incident into the knowledge base only after an accountable reviewer confirms the facts, applicable scope, effective date, source citations and retention rules. Correct prior versions without erasing their history. Keep evaluation holdouts out of training and out of answer-bearing retrieval used for the test.

Fine-tuning changes Gemma’s weights or adapters; adding a document to RAG does not [G1]. Curate reviewed examples, version the data and model, compare with the unchanged baseline on held-out cases, and retain rollback. OpenAI output can suggest an explanation to investigate; it must not become approved knowledge or a training label automatically [O2].

Failover must preserve the whole conversation

A healthy second inference process is necessary but insufficient. The surviving path needs authorized source access, durable inbox and reply outbox, conversation state, idempotent action records and a usable ingress route. Identify dependencies that could fail both nodes: shared power, storage, switches, identity, database leadership and gateway.

A proposed recovery sequence is: detect and confirm failure; stop the old writer from acting; establish the new permitted leader; reconstruct session and evidence state; retry only safe, idempotent work; verify delivery acknowledgments; and resume normal routing only after an explicit recovery check. A two-node network partition needs a reviewed fencing or independent-witness design; active-active inference does not imply multi-writer database safety.

Test host failure, GPU-process failure, database-writer failure, lost network reachability, stale replica, expired identity, unavailable Odoo/monitoring source and cloud loss separately. Define recovery time and acceptable data loss before testing, then measure them. Document what is unavailable in degraded mode rather than fabricating a normal answer.

Restore testing is distinct from file backup and replica synchronization. A recorded database restore does not certify complete application recovery. Preserve source versions, model artifacts, configuration and recoverable conversation/action state, and rehearse return to the primary without duplicated customer replies.

Operations, observability and ownership

Trace every inbound event to authentication, selected service, evidence snapshot hash, model output, validation, human review and delivery acknowledgment. Distinguish queued, running, partial, failed, escalated and delivered outcomes instead of calling every valid API response a success.

Observe ingestion/source freshness, permission revocation, retrieval citation resolution, active generations, queue depth, GPU/host memory, latency and recovery. Treat health signals by their actual observation scope; local process liveness does not prove a working customer path.

System Management owns accepted architecture pointers and release governance; component teams own technical contracts; Support reviews conversational usefulness; Accounting owns financial authority; infrastructure owns recovery evidence. Public website documentation is not an operations controller.

A proposed customer identifier distinct from circuit DAT and a single authoritative pricing-source principle require field ownership, migration/contract review and downstream acceptance. Neither is automatically a completed integration. Staff names and private source paths remain out of this public document.

25 workstreams, with explicit next steps

This is a public coordination register. Project roles are coordination responsibilities, not fabricated personal assignments or acceptance signatures. Expand any row to see the evidence stage, next deliverable and release gate.

25 / 25

The 20-layer responsibility map

Preserve the original design’s responsibilities while extending deployment, recovery and evaluation around them. A layer in the plan is not proof that its production integration is complete.

From evidence to a controlled pilot

Gate 0 — Reconcile engineering authority, current installed observations, source owners, version pointers and outstanding contradictions. Do not overwrite accepted plans with documentation candidates.

Gate 1 — Qualify the second independent GPU host and prove that a complete pinned model operates within host power, memory and cooling limits. An ordered card or an installed service is not failover acceptance.

Gate 2 — Prove hosted customer identification and scoped retrieval. Complete the currently blocked staging checks for DAT-family ambiguity, service pagination, grant expiry, fallback, source refresh, financial permissions and real end-to-end routing.

Gate 3 — Select exactly one current cloud reference model by verified model ID and approved policy; compare frozen minimized conversations and evidence with Gemma. Human reviewers adjudicate relevance, correctness, safety and Spanish-language quality on unseen holdouts.

Gate 4 — Test sustained load at 1, 2, 4, 8, 12 and 20 active requests plus an approved stress case. Repeat on a single surviving host with background knowledge jobs, full/degraded service separately, and no duplicated or unauthorized delivery.

Gate 5 — Authorize a narrow pilot with documented business, support, security and engineering acceptance, monitoring and reversal. Active/active routing or fine-tuning follows measured safety and quality improvements, not assumptions.

The development record

A living plan with an auditable history

The public architecture should be reviewed twice weekly and remain independent of daily homepage progress. Use updated accessible source inventories, component tests, management checkpoints and visible user/assistant decisions. Do not silently change accepted engineering versions.

The architecture publisher and midnight homepage publisher must share one per-site lock and protect current live files, original homepages and removed archive cards. The earlier broad architecture activation was blocked before execution; a new draft and a working homepage publisher are not permission to evade that previous security restriction.

Keep evidence snapshot date distinct from an actual confirmed website publication with seconds in Costa Rica time. On failed or unchanged work, preserve the prior published timestamp; a generated HTML file or an unattended schedule is not live verification.

Complete cloud ChatGPT history and the final v16 engineering attachment were not fully obtained. That is an evidence-coverage limitation, not grounds to invent status. Documentation may be prepared independently; activation follows the site-specific approved publishing gate.

Source basis, confidence and publication boundary

Internal basis: System Management v15 and October 30 v16 checkpoints; October 31–November 3 verified component reports for customer context, API integration, archive routes, conversation ingestion, cache trials, SOP review and local-model evaluation; selected visible conversation records; and the October 30 two-host decision briefs. An authenticated owner scan rediscovered 67 ADN-prefixed repositories, while the preceding daily publisher separately inventoried 68 owner repositories; the latter reviewed 21 window commits that were backup-only. Forty-two original source locations were rechecked and recent component evidence was reviewed. This is not a claim of complete cloud-chat, source or production coverage. Detailed paths, hashes, transcripts and sensitive findings are kept in the private release evidence.

External references support specific engineering principles and hardware specifications only. They do not verify ADN’s installed system. The evaluation plan is implementation-neutral and does not depend on the continuing availability of a particular vendor evaluation product.

1. [N1] NVIDIA — GeForce RTX 5090 specifications · checked 30 October 2026
2. [O1] OpenAI — Evaluation best practices · checked 30 October 2026
3. [O2] OpenAI — Optimizing LLM accuracy · checked 30 October 2026
4. [G1] Google — Gemma model fine-tuning · checked 30 October 2026