How Paloren builds a company brain: the technical specification

The request is: "What is unresolved for account A-104 before its renewal review?" The contract separates the customer identity from the identity of the person asking.

• Account A-104 maps to CRM account C-482 and help-desk organisation H-77 in an approved crosswalk. Each mapping keeps its source ID, verification date and owner. Similar company names alone do not authorise a join; an unmatched record stays in a review queue.
• Signed-in user U-18 maps to the source-system user and current account-reviewers group. The application checks both the account boundary and source permissions. An unmapped user or unavailable permission check receives no protected content.
• The CRM owner defines renewal_date; the service owner defines an unresolved issue as open or pending, excluding merged duplicates. Each imported record carries source_id, account_id, source_updated_at and ingested_at.

Two approved issues are in scope: T-31 is open and T-44 is pending. A versioned query over the permitted structured rows returns an unresolved count of two. The language model does not estimate the count from retrieved text.

• Meeting note N-12, version 3, says: "The customer requested Friday delivery; operations has not confirmed." Retrieval returns that passage with its document ID, version and source link. It is evidence of a request, not an agreed delivery date.
• Expected brief: "Two unresolved issues: T-31 and T-44. Friday delivery was requested but is not confirmed in N-12 v3." The count links to its permitted record evidence; the statement links to the exact note version.
• Keep the original note in its source system. If the design indexes passages or embeddings, register those copies and their permissions too. Notes provide context; an approved record definition decides a metric. Conflicts remain visible for review.

In this example, the connector can ingest more than U-18 may read. Connector access is not permission to disclose that content to the user.

• Filter structured rows and candidate document passages before they reach the model. Revalidate the source permission version before returning an answer, and withhold the answer if access changed during generation.
• When U-18 loses access to N-12, the next request must omit its passage, title and citation. Permission-sensitive answer caches are invalidated on access changes and checked again on reuse. The model is never asked to enforce access by following a prompt.
• The same boundary covers exports, search snippets and diagnostic traces. Restrict operator access to logs and avoid copying document bodies into them. A source document saying "ignore the rules" is treated as source text, not an instruction.

The ticket feed has a maximum age of 30 minutes. A last successful sync at 09:00 cannot support a current-status answer at 09:45. The brief labels issue status unavailable rather than presenting the old count as current.

• Track source update time separately from successful ingestion time. A retry does not reset the freshness clock unless fresh source data was received. Show the last verified timestamp and route a missed-sync alert to the technical operator.
• A deletion event for N-12 first blocks the document from retrieval, then removes derived passages and embeddings and invalidates dependent cached answers. Reconciliation checks catch missed events; a failed deletion job keeps that source blocked until verified.
• The deletion acceptance record names every derived store checked. Backup retention and any already-exported brief have separate handling agreed with their owners; deleting an index entry is not a promise that every copy has disappeared.

Run evaluation cases with a versioned fixture pack, including source snapshots, role assignments, query definitions and model configuration.

• Correctness: the baseline answer must report two unresolved issues, cite T-31 and T-44, and preserve the unconfirmed status in N-12 v3. A statement that Friday delivery is promised fails review.
• Isolation: ask as U-18 after revocation and as a user assigned to another account. Neither response, citation nor reusable cache may expose N-12 or unauthorised account records. Any disclosure blocks release.
• Recovery: simulate the 09:45 stale feed, delete N-12, replay an ingestion event and supply an unmatched account ID. Require a stale-data warning, no deleted passage, no duplicated issue and an explicit unresolved identity respectively.
• Evidence: retain each case ID, fixture version, user role, retrieved source IDs, actual answer, expected result, reviewer decision and defect reference. All required cases must pass the agreed gates; an overall quality average cannot excuse a permission failure. Business and technical owners sign the go, revise or stop record.

A read-only release still needs someone responsible when a source changes. The handover assigns roles to named people before live use, not to a shared inbox with no accountable owner.

• The business owner owns the question set and accepts the briefing quality. CRM and help-desk owners approve definitions and identity corrections. The document owner maintains approved versions; the identity administrator owns group membership and revocation.
• The technical operator monitors sync age, deletion queues, denied-access checks and retrieval failures. The runbook explains how to disable a source, invalidate affected answers, notify users and verify recovery before re-enabling it.
• Changes to connectors, business definitions, permissions, retrieval or the model trigger the affected evaluation cases before release. Agree support hours, escalation, running costs and the party responsible for each task separately. Creating tasks or updating the CRM is a later, separately accepted action workflow.