Skip to Content
PlatformExplanationAbout licences

About licences

The Evidence agent reads open literature and knowledge sources and the console renders passages from them. Rendering a passage is a licence question, and the console answers it per chunk rather than per source. This page explains the reasoning; the licence codes reference lists the codes and their rendering.

The problem

Open sources are open to different degrees. A record’s metadata may be public domain while its abstract is the publisher’s; an open-access article may forbid derivatives; a reconstructed abstract from a citation graph carries the publisher’s rights unless the location’s licence says otherwise; a notebook entry belongs to the customer. Treating a source as “open” wholesale would render text the licence does not allow, and calling a set of licences “commercial-clear” would hide the differences that matter.

One code per field, stored where it differs

Eight codes (cc0, cc_by, cc_by_sa, cc_by_nd, cc_by_nc, publisher_copyright, customer_internal, unknown) are stored on documents, on chunks and on sources. When a field differs from the document (the abstract inside an open record), the chunk carries its own code and rendering follows the chunk being cited. Abstracts default to publisher_copyright unless the source’s licence field is clear; reconstructed abstracts follow the location’s licence when it is explicit. The literature adapters read licences from the fields the sources publish, verified on 2026-09-14 and recorded in the contract.

Why no-derivatives is quote-only

A cc_by_nd chunk may be quoted verbatim with attribution but not paraphrased. The chunk is marked quote_only, the context assembler labels it “quote only, do not paraphrase” for the agent, the export lists such passages separately as quotations, and a paraphrased claim whose only sources are no-derivatives material is a citation-coverage warning. Non-commercial, publisher-copyright and unknown material is never rendered: the reader gets the locator and an outbound link.

Why customer content stays inside the program

ELN entries and SOP renditions are customer_internal. Their excerpts are shown to program members by design: the control is program membership plus the source system’s own project scoping, and document_chunks carries organization_id and program_id so every vector or text query filters on the chunk row. On export they leave as locator and hash only. When the source is deleted, the connection disconnected or the tenant offboarded, the documents are archived, and after the hold period (document_hold_days, default 30) the chunks, embeddings and stored objects are purged while the locator and hash stay.

Why documents are a cache, not a proposal

Fetching a document is a read-side action: knowledge.fetch_document writes documents and document_chunks as actor_kind = system and audits document.ingest; no approval gate applies. Registering a sources row in Evidence, by contrast, is a record write and therefore a gated proposal. Fetching is by identifier only (identifier_scheme, identifier_value) through one of the eight sources, under 25 MB and with a content-type restriction, so the platform never fetches an arbitrary address.

Attribution

Exports and reports that include content from a knowledge source carry that source’s attribution block from shared/knowledge-attributions.json, rendered verbatim; the adverse-event source’s block states that the existence of a report is not proof of causation. Legal review of that file is a gate before the pilot goes live.

Last updated on