Trueness.ai enterprise models, API and MCP plan
25 October 2026. The web workspace and assistant integrations use the same programme, brand/agency grants, audience versions, budgets and Calibration Records. Read-only MCP is an anchor-pilot deliverable by M3. Later write tools run the same controlled jobs as the six everyday actions; an assistant never bypasses the method or tenant boundary. Nothing here is a claim that the product integration has been built.
Platform and model decisions
The proposed Node/TypeScript application, Postgres, private object storage, durable workflow engine and Python statistical workers in platform.md are reasonable architectural choices for the pilot. Supplier API availability must be checked per provider; controlled file transfer with the same manifests is the fallback. SSO, tenant isolation, custody and auditability are launch gates. A SOC 2 Type I report depends on an actual independent examination and cannot be guaranteed by a software milestone.
Use a provider gateway with explicit model/configuration manifests, capability limits and cost metering. Compare the strongest available frontier candidates for difficult reasoning and audience development; choose the production recipe on developmental evidence, latency and operational cost. Verify current account access and provider versioning at procurement. Model catalogue labels do not prove suitability or predictable latency. See the OpenAI catalogue and Anthropic catalogue.
| Work | Proposed implementation | Promotion criterion |
|---|---|---|
| Protocol and difficult research synthesis | Strong reasoning model drafts; research lead decides | Correct sources, preserved uncertainty and useful reviewer effort |
| Panel reactions | Frozen audience/evidence configuration, explicit response schema | Development evaluation then prospective cell-specific human comparison for any quantitative claim |
| Verdict | Structured synthesis of the complete Panel and permitted evidence | Faithful representation of disagreement; no invented measurement |
| Challenge | Separately instructed critic, different provider where useful | Finds material errors; unresolved disagreement remains visible; provider diversity is not human independence |
| Talk | Versioned illustrative character context and permitted evidence | Generated label, scope limits and no claim to be a real respondent |
| Ask the research | Grant-filtered retrieval with source/page/base/date | Relevant citation, contradiction preservation and insufficient-evidence behaviour |
| Extraction/classification | Lower-cost model after a task benchmark | Required-field accuracy, complete source lineage and escalation |
| Statistical evaluation | Versioned Python code with deterministic checks | Correct human sampling units, weights, uncertainty and reproducibility |
| Billing, permissions, releases | Application services and named human approvals | Contract/grant/state rules, idempotency and recorded authority |
Choose one candidate before opening a final holdout. Store all developmental trials and rejected configurations. Do not select a winner using the same sealed outcomes later presented as independent validation. More simulated voices or agreement between models is not a larger human sample.
Version change is an included programme obligation
Manifest provider, returned model metadata/snapshot where available, prompt hashes, extraction/retrieval snapshot, grounding, numerical mapping, tool versions and settings. Providers may not offer immutable snapshots; log that limitation, use sentinel tests and track retirement notices.
A materially changed model, prompt, retrieval pipeline or mapping produces a new candidate and affected-record register. Development-only tests decide whether fresh prospective human confirmation is required; behavior-changing revisions need appropriate new evidence before extending quantitative claims. Old opened holdouts may diagnose but cannot independently validate a tuned replacement. The external reviewer and custodian retain separate roles.
The existing validated version or validated fallback may serve while available. Otherwise restrict affected claims and offer clearly labelled exploratory use when permitted. Historical outputs remain immutable. Included-scope remediation/revalidation is funded from the programme and reserve; it is not an automatic upsell. Expanded market/audience/task scope is separately agreed. See SOP16.
Cost and performance controls
Production AI allowances are $20k/$15k/$10k per reference programme-year in the low/mid/high scenarios. They are cost hypotheses, not measured bills. The wider Enterprise cadence comparison uses $30k. Central platform engineering is $600k/$750k/$900k in year one and includes development/test infrastructure; production usage and per-client delivery engineering are separately identified to prevent double counting. See the financial case.
Meter every call, attachment-processing step, retry and repair by programme, brand, agency, action, audience and version. Reserve spend before jobs; apply both interactive and formal-study entitlements. A monthly fee does not mean unlimited inference. Cache only permissioned content within the grant/version boundary. Provider billing and retention rules require account-specific confirmation; consult OpenAI pricing, Anthropic pricing and OpenAI data controls.
Use fixed maximum attempts for transport failures and a dead-letter/exception queue. Repeatedly sampling until a desired answer appears is not error recovery. Stream progress and partial reactions but label completeness. Benchmark the short-static-input latency target and p95 under concurrent agency load before making a service promise. Large documents or unsupported media receive explicit alternative handling.
Delivery sequence
| Stage | Surface | Release gate |
|---|---|---|
| M1–M2 | Thin web workspace and immutable PDF/JSON exports | Client/agency boundaries and protected holdouts exist before two-market intake; pilot is already multi-market |
| By M3 | Private read-only MCP for the anchor's authorised agency, backed by internal API | User-specific OAuth, grant-filtered records, audit/revocation/isolation tests and useful customer workflow |
| M2–M4 | Full six-action web workflow and agency administration | Scope/cost visibility, partial-input handling, usage telemetry and routine exploratory jobs without per-click researcher approval |
| M4–M8 | Scoped API/webhooks and MCP job creation | Versioned schema, confirmed scope/spend, idempotency, cancellation and permission rechecks |
| M8–M14 | Qualified licensee/group workflows; packaged assistant distribution if useful | Cross-brand rights, signed review authority, support capacity and host-platform eligibility |
These are build gates and sequencing assumptions. Agency identity separation exists before any agency data/access; a later administration screen does not justify an earlier shared account. API/MCP usefulness is tested in the anchor pilot, not postponed until two other buyers exist.
OpenAI and Claude document remote MCP support. Availability and administrative controls vary by account; confirm the actual client tenancy. These documents establish technical feasibility, not marketplace approval or compliance: OpenAI MCP, OpenAI plugins, Claude remote connectors.
API and MCP contract
| Tool/operation | Stage and purpose | Required permissions and output |
|---|---|---|
list_audiences |
Pilot read | Only granted audience/market/task scopes with current status and record links |
get_calibration_record |
Pilot read | Released authorised record; human bases, uncertainty, expiry, conflicts and scope |
get_panel_result |
Pilot read | Immutable released Panel/Verdict/Challenge with labels and input completeness |
get_export |
Pilot read | Authorised existing export; access-checked download, no unrestricted storage URL |
estimate_panel |
Later estimate | Validate stimulus IDs, grant, recipe, entitlements and cost ceiling; no execution |
run_panel |
Later job creation | Exact user-approved request/estimate, stable idempotency key, current grants and budget |
request_verdict / request_challenge |
Later controlled jobs | Operate on a permitted immutable run; meter incremental inference; do not silently change its record |
talk / ask_research |
Later generated interactions | Character/corpus grant, cost budget, generated/source labels; never sealed outcomes |
get_job_status / cancel_job |
Read / later write | Authorised job state, partial completion and cancellation cost consequences |
request_human_followup |
Later draft request | Creates a scoped quote request, not a recruitment purchase |
Read-only means existing permitted evidence/results in the first release. Generating new research answers or running a Panel is a separately budgeted operation even if it feels like reading. Quantitative evidence status is server-generated metadata, not text the assistant is trusted to remember.
The structured response contains programme_id, brand/agency grant, audience/configuration/record IDs, task and market, evidence type, current status, historic and fresh-human bases, limitations, expiry, processed-input manifest and source references. Reports remain useful outside the assistant. Webhooks are signed, replay-safe, scoped and idempotent; they carry event IDs and authorisation-protected references rather than private raw data.
Tenancy, authentication and tool boundaries
Use user-specific OAuth and resource-scoped grants, not a shared all-client API key. Validate issuer, audience/resource, scopes, token lifetime and membership server-side. Agency identities can belong to several clients but each request selects one permitted brand/project/grant. Query filters, embeddings, caches, jobs and downloads enforce the same boundary. OAuth consent does not by itself authorise a brand's proprietary source collection. See the MCP authorisation specification.
Disallow arbitrary SQL, direct payments, raw participant exports, provider secrets, model-release actions, unrestricted URLs and holdout answers as assistant tools. Treat source documents as untrusted evidence, not instructions. Recheck grants before worker execution and before returning content; revocation stops new access and scheduled jobs. Preserve historical audit records under retention terms without retaining stale access.
Anchor acceptance and continued investment
A delegated agency planner retrieves the right record and existing result in its assistant, sees a denied cross-client request and loses access on revocation. The researcher can reconstruct the request/grant/version from the event log. The client can use the exported evidence without the assistant. These are the pilot integration gates.
Then assess actual repeated use, steps saved, completion/failure rate, support minutes and cost per useful outcome. Add write tools when the controls and workflow pass, not merely because the protocol supports them. No integration, performance, security or calibration gate is claimed to have passed by this planning document.