A developer-facing docs site that is structurally broken at the platform level: 4 duplicate-set canonical models, 4 empty 'Untitled' published pages, 3 confirmed 404s on prominent URLs, an llms-full.txt that contains <2% of the actual documentation surface, and a directly contradictory privacy claim about whether customer data reaches third-party LLMs. Beyond the structural issues, several beta-feature pages omit the security/scope details (org-wide chart visibility, alert channels, chat-history retention) that any procurement reviewer needs to clear the product.
1. llms-full.txt is effectively empty — agents cannot index this product (critical)
Problem: The published llms-full.txt contains only three model sections — Ads, Sessions (Chord OMS), and Sessions (Salesforce, a near-duplicate) — and ends with a [Content truncated due to length...] marker. The site's sitemap.xml lists 268 documentation URLs, none of which (apart from those three) are represented. There is no introduction, no product index for Chord AI / CDP / OMS / Event Tracking, no SDK reference, no API reference, no changelog.
Consequence: AI coding agents (Claude Code, Cursor, Copilot) that fetch llms-full.txt to ground their answers will have effectively no knowledge of Chord beyond two duplicated tables. Developers asking 'how do I install the analytics SDK?' or 'what is the audiences API?' will get hallucinated answers with no usable retrieval signal. The file is worse than missing — its presence signals coverage that does not exist.
The fix: Regenerate llms-full.txt from the full sitemap, or at minimum a curated set including /getting-started, /configuration, /sdk-api-reference, /server-events-overview, /order-completed, /audiences-api, /web-pixel, /oms-schema, and the Chord AI feature pages. Either remove the truncation cap or split into chunked llms-full.txt shards.
2. Direct contradiction on whether customer data is sent to third-party LLMs (critical)
The Chord AI FAQ states verbatim: . The companion page states verbatim: and — i.e., Anthropic, an external AI provider, is the model engine for Chord AI's two primary capabilities. The 'multi-LLM architecture' explanation in the FAQ does not reconcile this: SQL generation by Claude Opus necessarily involves sending schema and question text to Anthropic.
'no chord ai processes your data within our platform and does not send any raw business or customer data to external ai providers'
/chord-ai-models-powered-by-anthropic
'Claude Haiku 4.5 — handles response generation and classifications'
'Claude Opus 4.5 — powers sql generation'
Consequence: This is the single highest-stakes claim in the docs. Security and compliance reviewers at customer organizations will read the FAQ and approve Chord; their engineers will then read the Anthropic page and discover the claim is materially misleading. At minimum it triggers a re-procurement review; at worst it is a contractual or regulatory issue (CCPA, EU data transfer).
The fix: Rewrite the FAQ answer to precisely describe what reaches Anthropic (e.g., 'schema metadata, question text, and aggregated/sampled values reach Anthropic; raw row-level customer PII does not'). Cross-link the two pages. Define 'raw business or customer data' explicitly.
3. Three high-prominence URLs return 404, including one that is the top Google result (critical)
Problem: All three URLs render Archbee's 'CONTENT NOT FOUND' page. /chord-commerce-data-platform is publicly indexed as the first Google result for 'Chord Commerce Data Platform' against site:docs.chord.co. /sdk-reference is the URL that surfaces in Google search snippets as 'SDK Reference - Chord Commerce'. /installing-chord-analytics is bulleted as a 'Key Resource Available' on the live /chord-event-tracking landing page.
Consequence: Developers and agents arriving via search land on dead pages for the product's flagship developer surfaces. The internal link from /chord-event-tracking is a self-inflicted dead link inside the docs themselves.
The fix: Add 301 redirects: /sdk-reference → /sdk-api-reference; /chord-commerce-data-platform → /chord-data-platform; either build /installing-chord-analytics or fix the link on /chord-event-tracking to point to /installation.
4. Sitemap is polluted with hash-prefixed duplicate pages of every major data model (critical)
Problem: The sitemap exposes 268 URLs, with systematic duplication of canonical model pages under 4-character hash-prefixed slugs. Examples of confirmed duplicates: Sessions has 4 versions (/sessions, /q_lb-sessions, /oEDf-sessions, /ykTU-sessions); Orders has 4; Ads has 3; Activities has 3; Users has 3; Marketing Attribution has 4; Conversions has 3; Line Items has 3; Sales has 3; Subscriptions has 2; Klaviyo has 2; Facebook Pixel has 2; GA4 has 2; Configuration has 2. Even /llms.txt itself notes 'duplicate entries for topics like Sessions, Orders, Users, Activities, and Conversions'. There is also an unfinished /sharing-data-with-chord-from-cloud-storage-cloned.
Consequence: (a) Agents indexing the sitemap retrieve N copies of the same model with subtly divergent content — see finding #5 for a concrete example. (b) Search engines split PageRank across duplicates, downranking the canonical page. (c) Internal docs links that use Archbee docid: references can point to either copy with no human-readable indication of which is current.
The fix: Pick a canonical slug per model (/sessions, /ads, /orders, …), 301 every hash-prefixed sibling to it, exclude unpublished drafts from the sitemap, and configure Archbee to stop emitting hash-prefixed slugs for unpublished revisions.
5. Critical session-timeout fact is on only 1 of 4 Sessions pages (significant)
Problem: The definition of what a session actually is — 'a collection of activities performed by an anonymous or identified user on the website' terminating 'after 30 minutes of inactivity' — appears only on /ykTU-sessions. The canonical-looking /sessions page lists 100+ field attributes but never defines the session boundary. The 30-minute timeout is the single most consequential semantic in any analytics product.
Consequence: A developer doing attribution math (e.g., comparing session counts to GA4 or Segment, where the default is also 30 min but configurable) cannot find this fact at the canonical URL. Agents grounded on /sessions will answer 'how does Chord determine session end?' incorrectly.
The fix: Move the session definition and inactivity timeout to the top of the canonical /sessions page, then collapse the four sibling pages (see finding #4).
6. SDK version pinning is inconsistent and stale across install paths (significant)
Problem: The package release notes show @chordcommerce/analytics v1.22.2 shipped on May 4, 2026, fixing identity-bleed on logout ('identify/track/page now await in flight reset() before sending'). But /custom-storefront-installation step 1 instructs npm install @chordcommerce/analytics@1.21.3 — a hard pin to a version missing the identity-bleed fix. The Segment migration guide tells migrators to update 'to version 1.9.1 or newer' — a floor that is many minor versions and likely well over a year behind the current release (v1.0.0 shipped Dec 2023; v1.22.2 shipped May 2026).
Consequence: Developers who copy/paste the install command will install a known-buggy version; specifically, customers who follow the documented happy path will ship the identity-bleed bug fixed in v1.22.2. Migrators following the Segment guide will have no signal that the floor is wildly out of date.
The fix: Either drop the version pin (npm install @chordcommerce/analytics) or have CI auto-bump the pin to latest on release. Update the Segment migration guide to reference the current minimum. Add a top-level 'currently shipping' version banner derived from the npm tag.
7. Web pixel variable count contradicts itself across three install pages (significant)
Problem: Four pages describe the same setup variables and disagree on the count: /getting-started lists 5 values (CDP domain, CDP write key, OMS id, Store id, Tenant id). /configuration enumerates 7 const variables (adds default_locale, store_domain). /custom-storefront-installation step 4 explicitly says 'five required variables' (omits default_locale and store_domain). /installation lists 8 — adding pixel_version, which is not present in the canonical /configuration page at all.
Consequence: A developer cannot tell whether they have all required values from the 'Chord team'. Following /getting-started and stopping there ships a broken installation missing locale and store-domain. The pixel_version variable in /installation has no documented source, no schema entry, and no validation rules.
The fix: Make /configuration the single source of truth, mark each variable required/optional with default and validation rules, and have the other pages link out instead of restating the list. Resolve whether pixel_version is real and supported, and if so, add it to /configuration.
Problem: The Predictive Intelligence overview claims 'The platform includes 20+ predictive models'. The canonical /predictive-models page lists 6 (Customer Lifetime Revenue, Product Recommendations, Revenue Forecasts, Session Conversion Probability, Predictive Marketing Attribution, MMM). That is a 3.3x discrepancy on a marquee number.
Consequence: Sales/eval-stage developers who count what's actually documented (6) will lose trust in the '20+' claim. Agents asked to enumerate Chord's predictive models will produce conflicting answers depending on which page they ground on.
The fix: Either expand /predictive-models to enumerate all 20+ (with status: GA, beta, roadmap), or correct the overview to match the documented surface. Don't ship a marketing number with no list to back it.
9. Server-event auth header casing and parameter casing are inconsistent (significant)
Problem:/server-events-overview documents three auth methods with explicit casing rules: header x-write-key (lowercase, recommended); query param writekey ('all characters are lowercase'); body property writeKey ('uppercase k'). The companion /order-completed example shows the same header as X-Write-Key. HTTP headers are case-insensitive in practice but agents producing code from prose typically copy whatever casing they see — and case is meaningful on the body and query forms.
Consequence: A developer who copies the body-form auth from one page and the casing from another (e.g., writekey body property instead of writeKey) will receive auth failures with no obvious cause. The three auth surfaces with three casing rules is a footgun.
The fix: Pick one canonical casing (X-Write-Key is HTTP-conventional) and use it everywhere. Document the exact casing rules for the query and body fallbacks in a single table on /server-events-overview and link from /order-completed.
10. Event naming is inconsistent: 'checkout started' vs 'checkout created' (significant)
Problem:/server-event-tracking says the Shopify webhook checkouts/create produces 'Chord's checkout created event'. /usage lists the auto-tracked web-pixel event as 'checkout started'. /verifying-your-chord-implementation tells developers to 'trigger an event from backend (such as order completed or checkout started webhooks)' — using the storefront name for a backend webhook event.
Consequence: Any downstream destination (warehouse table, Klaviyo flow, attribution model) that filters on the event name will silently miss either the storefront events or the server events depending on which name they chose. Verifying an implementation against the docs is impossible because the verification page itself uses the wrong name.
The fix: Pick one canonical name per checkout lifecycle stage and document it in the tracking plan. Audit every page for the wrong name and fix; update the verification page to match the names server-event-tracking actually emits.
11. /track schema uses non-standard field names without explanation (significant)
Problem: The Track payload schema names the event-name field track (string, required, 'the specific event name (e.g., order completed)') and uses type for the event category. Segment and Segment-compatible spec implementations (RudderStack, Jitsu) use event for the event name and reserve type for the call-type discriminator (track/identify/page). The page does not flag this divergence.
Consequence: Developers porting from Segment will copy their existing event-builder code, send { type: 'track', event: 'order completed' }, and the field Chord requires (track) will be missing. With no error response shape documented (see #12), the failure mode is silent.
The fix: Either rename the field to event to match the Segment-compatible spec Chord otherwise mirrors, or add an explicit callout: 'Note: unlike Segment, Chord uses track (not event) for the event name field.' Provide a side-by-side Segment-vs-Chord payload diff.
12. /audiences-api is missing every API-doc fundamental (significant)
Problem: This is the only true HTTP API page in the docs (GET https://analytics-api.chord.co/audiences). It documents auth headers and one happy-path response. It does NOT document: error/status codes; rate limits; the response shape when no audiences match; pagination behavior; the Bearer token lifecycle (expiry, rotation); how to obtain a token (the prereq is 'API key from Chord (contact help@chord.co)').
Consequence: A developer integrating Audiences cannot write robust client code: there is no way to know if a 401 means 'expired token' vs 'wrong header'; no way to handle large audience lists; no way to plan for rate-limit handling. Agents asked 'what error codes can the Chord audiences API return?' will hallucinate.
The fix: Add an Errors section with the actual status codes and JSON error shape, a Rate Limits section, a Pagination section, and a Tokens section covering issuance, expiry, and rotation. Link to a self-serve API-key issuance flow rather than mailto:help@chord.co.
13. SDK API reference lists methods without signatures, types, or errors (significant)
Problem: The SDK reference enumerates methods (chord.page(), chord.identify(userid, traits), chord.reset(), trackProductViewed(), trackProductAdded(), trackProductRemoved(), …, chord.track(eventname, properties)) but provides no parameter type tables, no return-value schemas, no exception/error documentation, and no runnable code samples per method. The most an agent can infer is the parameter names from prose.
Consequence: Agents writing TypeScript client code will guess parameter shapes (is traitsRecord<string, unknown> or a typed object? Does trackProductAdded take a product object or scalar args?). Wrong guesses ship to production.
The fix: If the package ships TypeScript declarations, generate the SDK reference from them so signatures, return types, and JSDoc errors are guaranteed in sync. Otherwise, add hand-maintained type tables per method. Either way, add a runnable example for every method.
14. Release Notes page hasn't been updated since April 2024 while the SDK shipped through May 2026 (significant)
Problem: The canonical Release Notes page renders only navigation chrome with Updated 12 Apr 2024. There are no version numbers, dates, or changelog entries. Meanwhile /chordcommerceanalytics has a real changelog reaching v1.22.2 on May 4, 2026.
Consequence: A developer landing on /release-notes from the global nav reasonably concludes that nothing has shipped in over two years. Any auditor or compliance reviewer pulling 'most recent change history' from the canonical URL will incorrectly conclude the product is stale or abandoned.
The fix: Either populate /release-notes with the cross-product changelog (CDP, OMS, AI, web pixel) or 301 it to /chordcommerceanalytics. Best practice: keep /release-notes as the platform changelog index and link out to per-package histories.
15. Four empty 'Untitled' pages are published and indexed (significant)
Problem: All four pages render with title 'Untitled', read time 0 min, navigation chrome only, and no body content. /bv9m-untitled and /7IMs-untitled sit inside the 'Chord Event Tracking > Getting started' flow between /getting-started and /custom-storefront-installation — i.e., a developer paging through the install guide hits two consecutive empty pages.
Consequence: The published-empty pages signal abandoned drafts on a docs site that already 404s on three flagship URLs. Developers walking through Getting Started experience two dead-air pages in the middle of the install flow.
The fix: Unpublish the four Untitled pages from Archbee, fix the prev/next chain in 'Chord Event Tracking > Getting started', and add a CI check that fails publish on pages titled 'Untitled' or with empty bodies.
Problem:/chord-ai-technical-overview states verbatim: 'The system currently supports a single data source.' But /connect-data-sources lists 14+ available connectors (Amazon SP, Postgres, Facebook Ads, Google Ads, Klaviyo, Pinterest Ads, Recharge, Shopify, TikTok Ads, YouTube Ads, …) and /available-destinations lists ~190 destinations. The single-source restriction applies specifically to Chord AI's data-modeling/SQL-generation surface, but no page explains that scope boundary.
Consequence: A developer evaluating Chord AI for a multi-warehouse use case (e.g., Shopify + a separate subscription system) cannot tell whether the limitation is a fundamental product constraint or a Chord-AI-only constraint. Combined with 'connect 14+ sources' messaging on the sibling page, the apparent contradiction reads as marketing overreach.
The fix: State the scope explicitly: 'Chord AI today queries a single connected data source per organization; the broader Chord CDP / Data Platform ingest from N sources.' Add the limitation to the AI Implementation Guide as a precondition.
17. Chord AI is documented as both 'beta' and 'alpha release' (significant)
Problem: The Chord AI FAQ refers to the launch stage as 'During alpha release'. Every other Chord AI feature page closes with 'Chord AI is currently in beta' (charts, monitors, context, modeling).
Consequence: Customers evaluating production-readiness cannot tell which gate they're behind. Alpha typically implies invitation-only and breaking-change risk; beta typically implies feature-complete with stability caveats. Inconsistent labeling makes it impossible to write an accurate vendor-evaluation report.
The fix: Pick one stage per feature and use it everywhere. Add a 'Lifecycle' badge component to the docs theme so the stage is visually consistent.
18. OMS schema entity counts disagree across the two ingestion docs (significant)
Problem:/oms-schema enumerates 13 entities for ingestion (Orders, Customers, Products, Product Variants, Order Line Items, Locations, Payment Transactions, Order Line Refunds, Return Line Items, Fulfillments, Fulfillment Order Lines, Fulfillment Orders, Subscription History). /chord-data-source-ingestion-guidelines lists 10 minimum required entities (orders, customers, line items, products, variants, payments, returns, refunds, shipments, subscriptions) with different naming (shipments vs Fulfillments; no Locations, no Fulfillment Order Lines, no Fulfillment Orders).
Consequence: A customer building their export pipeline against the ingestion-guidelines page will ship 10 entity files; Chord OMS may then complain about missing Locations or Fulfillment Order Lines. The naming divergence (shipments vs fulfillments) means even file paths may be wrong.
The fix: Make /oms-schema the single source of truth for entity names and counts; have the ingestion guidelines link to it instead of restating. Resolve shipments vs fulfillments naming.
19. Server-side event context isn't auto-populated, and that fact is buried (significant)
Problem:/the-context-object states verbatim: 'Server-to-Server Events: Context is not populated automatically. Developers must explicitly include any context fields they need in the event payload.' and 'Geo: resolved from IP — browser events only.' This is a high-stakes architectural fact. It is not cross-referenced from /server-events-overview, /order-completed, or /server-event-tracking, and the order-completed sample curl does not show a populated context object. The same anti-pattern applies to /event-deduplication: the at-least-once delivery commitment and messageId idempotency guidance live on a single page that /server-events-overview does not link to.
Consequence: A developer following the order-completed example will ship server events with no UTM, no device, no geo, and no idempotency strategy. Attribution and reporting downstream silently miss the context dimensions, and retries on transient failures double-count events. By the time someone notices empty UTM columns or duplicated revenue in the warehouse, weeks of data are unrecoverable.
The fix: Add an explicit 'Server-side context is not auto-populated' callout to /server-events-overview and /order-completed, with a curl example that includes a fully-populated context object covering UTM, user agent, and IP-derived geo (since geo-from-IP doesn't run on S2S). Cross-link /event-deduplication from /server-events-overview and from each event-specific page.
20. Pinned AI charts are visible org-wide with no scoping (significant)
Problem: A single trailing line on the Chord AI Charts page reads verbatim: 'Currently, AI dashboards display all pinned charts across your entire organization.' There is no per-user, per-team, or per-role scoping; no security/permissions section calls this out; the FAQ's claim that 'Chord AI uses only the data that a given user is permitted to access' is undermined by the fact that any pinned chart — including a chart of revenue, top customers, or any other sensitive aggregate — is visible to every user in the org by default.
Consequence: A user with permission to query revenue can pin a chart and unintentionally expose that chart to every colleague who opens AI dashboards, including users without revenue access. This is a multi-tenant/least-privilege violation hiding behind a single sentence on a beta-feature page. Compliance reviewers reading the FAQ first and the charts page second will treat this as a blocker.
The fix: Add an explicit Permissions/Visibility section to /chord-ai-charts. Document who can see pinned charts, whether the chart's underlying data permission is enforced at view time, and what scoping (private / team / org) is on the roadmap. Cross-link from the Chord AI FAQ's 'Can I control what data Chord AI has access to?' answer.
21. Chord AI Monitors documents no alert delivery channels (significant)
Problem: The page describes monitors that 'continuously check the health and accuracy of your data queries, alerting you when something's off—before it impacts decisions.' But it never documents the alerting surface: no email/Slack/webhook integration, no anomaly threshold definition, no error behavior when the underlying SQL fails, no rate or volume limits, no on-call/escalation pattern. The user-facing actions are limited to run/pause/edit/view-history.
Consequence: A 'monitor' feature whose docs do not specify how you are alerted is an integration blocker. A developer cannot wire monitor alerts into PagerDuty, an incident channel, or a webhook responder without contacting their account manager — the only documented next step. Agents asked 'how do I get alerted when a Chord AI monitor fails?' will hallucinate channels that don't exist.
The fix: Add an 'Alert delivery' section listing the supported channels (email, Slack, webhook, …) with payload schemas; an 'Anomaly thresholds' section with the threshold types and configuration; and an 'Error behavior' section describing what happens when the monitor's SQL or data source fails. Mirror the structure of the /chord-ai-context instruction-types section so the docs symmetry is preserved.
22. /chord-ai-implementation-guide contradicts itself on engineering required (significant)
Problem: Step 1 of the implementation guide says verbatim: 'Familiarize yourself with your store's data warehouse models and prepare a list of key custom metrics, definitions, and important questions along with corresponding SQL queries relevant to your organization.' The same page elsewhere claims: 'you don't need a team of engineers or weeks of setup — simply connect your data source and chord takes care of the rest.' Preparing 'key custom metrics … and corresponding SQL queries' for an org's warehouse is precisely a task for engineers and analytics engineers.
Consequence: A buyer evaluating Chord AI on the marketing claim ('no engineers needed') will commit, then discover Step 1 of the implementation requires the kind of resource the page told them they wouldn't need. Internal expectation-setting is broken; CS escalations follow.
The fix: Reconcile the two statements on the page. Either drop the 'no engineers' line, or move the SQL-preparation step to a 'Recommended' tier and provide a low-prep alternative (e.g., 'start with Chord-provided default metrics, layer in custom SQL pairs over time'). Be explicit about the staffing assumption.
23. /chord-ai-technical-overview claim 'does not store your data' is contradicted on the same page (significant)
Problem: Stage 2 of the technical overview states verbatim: 'Chord AI does not store your data; we simply work with your store's data schema.' Stage 1 of the same page describes a warehouse-sharing connection that includes 'schema/freshness/permissions checks'. Stage 3 describes a vector-DB lookup that 'always pull[s] the top results' — a vector DB by definition stores embeddings derived from data. The page does not reconcile what 'does not store' means in the presence of a vector store.
Consequence: A compliance reviewer comparing this page to the FAQ (#2) and to the Anthropic models page (#2) cannot determine what is actually persisted at rest, where, for how long, or under what encryption regime. The 'does not store' line is the kind of claim that becomes a contractual representation in security-review questionnaires; if it isn't precisely true, it must be precisely qualified.
The fix: Replace the blanket 'does not store your data' line with a precise statement: what is stored (vector embeddings of schema/metadata? sample values?), where (Chord-managed infrastructure vs. customer warehouse), retention, and encryption. Cross-link to the FAQ's privacy answer.
24. Ads model attribution conflict between Data Platform and OMS (minor)
Problem:/ads describes the Ads schema as part of 'Chord Data Platform for Shopify integration'. /c2Te-ads describes the same schema as belonging to 'Chord's OMS (Order Management System), which aggregates advertising data from multiple sources including Google, Facebook, TikTok, and YouTube.' Two pages, identical schema, contradictory product attribution.
Consequence: A buyer trying to figure out which SKU (Data Platform vs OMS) gives them ads aggregation cannot tell from the docs. Sales-engineering escalations follow.
The fix: Resolve which product owns Ads aggregation, label the canonical page accordingly, and 301 the duplicate (per finding #4).
25. /available-destinations splits 'Crowd.dev' into two phantom destinations (minor)
Problem: The destinations list contains the consecutive entries 'CJ Affiliate, CleverTap, ClickUp, Constant Contact, Courier, Criteo, Crowd, Dev, Customer.io, Databricks, …'. There is no platform called 'Crowd' and none called 'Dev' — these are clearly the result of Crowd.dev (one platform) being split on the period during list rendering. The same artifact appears on /chord-cdp.
Consequence: A developer searching for 'Crowd.dev' won't find it under its real name; the list also misleads anyone counting available destinations.
The fix: Fix the destinations source list (likely a CSV or spreadsheet that lost a quoting rule) so 'Crowd.dev' appears as a single entry.
26. Destination count: '160+' vs ~190 listed (minor)
Problem:/data-activations claims the product syncs to '160+ marketing and operational platforms'. /available-destinations enumerates roughly 190 destinations by name. That's a ~30-destination gap between the marketing claim and the documented surface, separate from the Crowd.dev parsing artifact in #25.
Consequence: A buyer comparing the headline number to the actual list either believes the 160+ figure is conservative (and undersells what's available) or doubts whether 30 of the listed destinations are actually production-ready. Either way the credibility of the integration count is undermined.
The fix: Reconcile the two pages: pick one number that matches the actual supported set, mark each destination on /available-destinations with status (GA / beta / coming soon), and have /data-activations cite the live count rather than a stale rounded figure.
27. Internal Archbee docid: references leak into published install instructions (minor)
Problem: Steps 4 and 5 of the Shopify install link to other docs pages via Archbee internal docid: references (docid: dbkzuyyjshkx7dzhisfez for the consent guide; docid: qmm8kz1wshyjhs9qbh0vm for /configuration) instead of human-readable URLs.
Consequence: When the link rendering breaks (or for users reading the page in any non-Archbee context — copy-paste into Slack, agents fetching prose), the references resolve to opaque hashes instead of paths developers can follow.
The fix: Replace Archbee docid: link tokens with the canonical published URLs. Add a CI/build check that fails publish when raw docid: strings appear in rendered prose.
28. Chord Copilot Chat history retention and cross-user visibility are unspecified (minor)
Problem: The Copilot Chat page documents 'new conversation/history controls' but never specifies how long chat history is retained, who within an organization can see whose chat history, or what error states surface when generated SQL hits a permission boundary. Combined with the org-wide pinned-charts behavior in #20, the 'who can see whose data' surface for Chord AI is documented in fragments rather than as a coherent permissions model.
Consequence: Compliance reviewers cannot answer basic questions ('does an admin see all employees' chat history? are user prompts persisted indefinitely?') without an account-manager call. Customers handling regulated data (healthcare commerce, EU users) cannot complete a DPIA from the docs alone.
The fix: Add a Permissions and Retention section to /chord-copilot-chat covering: history retention duration, deletion controls, cross-user visibility (per-user only vs. admin override), and the failure mode when a generated query exceeds the user's data permissions.
29. Pre-January-2025 customers have no documented Chord CDP migration path (minor)
Problem: The page states 'all new Chord customers after January 2025 will leverage Chord CDP upon signing up' — implying older customers are on a different stack — but it does not link to or describe a migration path for the pre-2025 cohort. The Segment-to-Chord migration guide at /migrating-from-segment-to-chord-cdp is targeted at customers leaving Segment, not at existing Chord customers on the older stack.
Consequence: An existing Chord customer who reads the page and wants to know 'am I on Chord CDP, and if not, how do I get there?' has no documented next step beyond contacting support. Internal account managers absorb the load.
The fix: Add a 'Existing customer? See your migration path' callout linking to per-cohort migration docs (or, if those don't exist, write them). At minimum, document how a customer can determine whether their org is on Chord CDP today.
What they do well
/oms-schema is a strong reference page with clear format standards (ISO 8601, lowercase booleans, ISO 3166-1 alpha-2, null-not-empty-string), enums for status fields, and explicit edge-case guidance ('if your system doesn't use variants, create one variant per product').
/event-deduplication makes a clear delivery-semantics commitment ('at least once') with concrete dedupe guidance per destination class (warehouse via merge on messageId; HTTP via idempotency-key header) — but the content is undermined by not being cross-linked from where developers actually arrive (see #19).
/the-context-object correctly distinguishes browser-vs-S2S behavior and gives best-practice guidance for server-side payloads — the content is good, it's just not cross-linked from where developers actually land (see #19).
Top 3 recommendations
Fix the platform-level breakage first: regenerate llms-full.txt, redirect the three 404s, collapse the hash-prefixed duplicate sitemap, and unpublish the four 'Untitled' pages. These are the issues that make the docs look abandoned to both humans and agents.
Reconcile the privacy and permissions story end-to-end — the Anthropic/data contradiction (#2), the 'does not store' overclaim (#23), the org-wide pinned charts (#20), and the Copilot Chat scope gap (#28) are the same procurement-blocker viewed from four angles. Write one canonical 'How Chord AI handles your data' page and link it from every AI feature page.
Make canonical pages the single source of truth for the install variables (/configuration), entity list (/oms-schema), event names (a tracking-plan page), and SDK version (the npm latest tag). Have every other page link in, not restate.