Integrate / Observation permissions

Observations and permissions

An observation is a submitted example of language with provenance and declared permissions. It is not automatically an accepted sense, a public corpus entry, or a training example.

Explicit submission#

Use submitObservation(input) only after a person or authorized operator chooses to contribute the material. Ordinary analysis should not silently submit the passage. The SDK guide and API reference describe the implemented request fields.

Separate permissions#

Analysis, display, redistribution, and training are separate permitted uses. A source being publicly readable does not grant all of them. Keep the rights basis and source identity attached to the record.

Private review first#

Submitted observations stay private until the required review and permitted uses support promotion. Machine-generated interpretations and proposed distinctions remain candidates. A generated explanation is not human validation.

Source provenance#

Preserve the source URL or external identifier, context, capture time, and available hashes. Do not remove attribution when a downstream product presents a shorter excerpt or summary.

Withdrawal#

A source withdrawal should prevent affected data from being used in later publication and disable access to affected releases under the current backend rules. Immutable on-chain commitments cannot erase historical records. Product caches and third-party copies need their own withdrawal handling.

Product boundaries#

Messages in What You Mean?, creator comments in Studio, drafts in Write, and organizational documents in Teams need explicit permission before entering the contribution workflow. An account login is not permission to publish private content.

See product integration for the implementation boundaries that neighboring products must preserve.