06-reference/research

akta monid tos data output rights

2026-07-21·research-brief·source: deep-research·by Ray Data Co (deep-research synthesis)
vendor-diligenceaktamoniddata-licensingprocurement

Akta & Monid ToS: Can We Use Their Data Outputs in Client Deliverables, and What Provenance Do They Disclose?

The question

Do Akta's and Monid's terms of service permit using their data outputs in client-facing deliverables and derivative reports, and what data provenance disclosures do they require? (Context: both flagged as explicitly unresolved in the 2026-07-13 vendor diligence; RDCO is evaluating them for client-engagement enrichment, where resale/derivative clauses are notorious consulting gotchas, and neither product page discloses whether data is scraped, licensed, or modeled.)

What we already know (from the vault)

What the web says

Convergences and contradictions

Synthesis for RDCO

Verdict: the ToS neither clears nor blocks client-facing use — it is unverified, which for a procurement gate defaults to NO-GO for any client-facing deliverable or derivative report until the actual license is retrieved and read. I could not find a public ToS for either Akta or Monid, so any claim that resale/derivative use is "permitted" would be fabricated. The honest state is: we do not yet possess the governing terms. For a consulting shop putting vendor data into client deliverables, the resale/redistribution/derivative-works clause is precisely the clause that most often prohibits the intended use, and it is the one clause we have not seen. Default to caution.

On provenance disclosure required of us: there is currently nothing to cite. Neither vendor discloses sourcing, so RDCO cannot make an accurate provenance statement to a client about this data, and cannot confirm it is free of scraped-source redistribution restrictions. Independent of the vendor's own (absent) attribution requirements, RDCO's own standard should be to label any Akta/Monid-derived field in a client artifact as vendor-sourced, third-party, unverified-provenance, and (for financials) modeled estimate — until the vendor discloses sourcing in writing. Do not present it as first-party or authoritative.

Conditions to attach to the procurement gate (all must clear before client-facing use): (1) Retrieve the actual API License / Terms — create an account and capture the click-wrap/checkout agreement, or request the MSA/terms from Akta (support@akta.ai) and Monid support in writing; (2) confirm in that document an explicit right to incorporate outputs into deliverables for third parties (clients) and to create derivative reports — a plain internal-use-only or no-redistribution clause is a hard blocker; (3) obtain a written provenance statement (scraped vs licensed vs modeled, per field) and a freshness/accuracy posture; (4) confirm attribution/source-disclosure obligations, if any, that would need to appear in the deliverable; (5) for the Monid path specifically, remember the parent doc's DIRECT-to-Akta verdict — Monid interposes a second counterparty and its own (also absent) terms, compounding, not reducing, the unresolved-terms risk, so if either path proceeds it should be direct to Akta.

What can proceed now without the gate: the parent doc's accuracy eval — pulling Akta profiles for cellar ground-truth companies (Kwik Trip, Lenovo, Novo Nordisk, US Foods, Salesforce) and scoring field-by-field — because that is internal, non-client, on completed/public entities. Eval feasibility is unaffected by the ToS gap; only client-facing/derivative use is blocked.

Why this is in the vault

This brief resolves the "rights to use outputs in client deliverables" line-item the 2026-07-13 diligence explicitly left open, and it directly gates whether Akta (and/or Monid) can be adopted as a source for the ab-company-research station and, downstream, used in phData/CAF client engagement enrichment. It converts an open question into a documented NO-GO-until-terms-retrieved decision with named clearing conditions.

Open follow-ups

Related

Sources