A14. Contributions
Status: normative. Document version 1.0-draft-1.
A14.1 Authority and transport
Version 1 uses authenticated HTTPS push: one event per POST /v1/proposals, or the identical propose_entry MCP tool. Maximum event body is 64 KiB. Batches, background polling, streaming subscriptions and vendor-specific export formats are outside v1. A connector repeatedly pushes within its bounded, separately revocable contribution grant; continuity does not imply perpetual permission.
Grant constraints are an exact domain/key allowlist, purpose, expiry, maximum accepted unique events and optional ordinary confirmation permission. A read grant cannot contribute; a contribution grant cannot read context, enumerate records, list other recipients or discover migration destinations. The current-grant endpoint is restricted to the authenticated grant and exposes no linked grants.
A14.2 Events and deduplication
contribution-event.json defines a discriminated create, correct or withdraw event. An event whose value_type or value does not match the key definition (A4.1) fails value_rejected. event_id is a contributor-scoped opaque ASCII identifier of 1 to 128 letters, digits, underscores or hyphens. Record the authenticated client as source; reject a body-supplied source client or ingestion time. The provider sets ingestion time from its trusted Clock. Occurrence time can describe past activity but must not exceed ingestion by more than five minutes; it does not backdate authority.
Uniqueness is (record partition, authenticated client, event_id), independent of a refreshed grant. Hash the canonical submitted payload with SHA-256 for comparison. An identical authorised retry returns the original acknowledgement; a differing payload under the same ID returns idempotency_conflict. A new correction uses a new event ID and names its predecessor. Accept and acknowledge transactionally, after rechecking current grant activity and limits. Identical retries do not consume another event allowance, but still require active authority and rate limits.
Retain deduplication identities and payload digests for the stream lifetime plus 30 days. Revocation ends that stream; reopening requires a fresh stream namespace communicated in the new contribution grant. A stream namespace is a UUIDv4 and is included in every event. The provider never accepts the old namespace under a new stream grant. Retired namespaces retain a non-content tombstone so old events cannot reappear after deduplication expiry. Digests and metadata remain protected, not public diagnostics.
A14.3 Corrections, withdrawal and provenance
Corrections/withdrawals may target only a previous event from the same client, stream and record. The full predecessor chain is bounded to 100 and cannot branch silently: a correction must reference the current head or fail proposal_decided. Source withdrawal stops disclosure of the contributed observation and invalidates dependent derivations. It cannot delete the person's independently confirmed declaration; instead flag the changed evidence for the person's review.
Event category distinguishes user_supplied, activity, observation and inference. Preserve it even after acceptance. Approval of a batch, client or general stream is not confirmation of a statement. Becoming declared requires explicit confirmation of the exact value and protected statement hash. The first-party app handles all sensitive or safety-critical proposals; all v1 confirmation occurs in the first-party app; third parties can request review only. inferable:false, safety and special-category prohibitions cannot be overridden by enabling a domain. For a special-category or safety-critical key, only a user_supplied event is accepted, and it remains a protected proposal until the person confirms it in the first-party app (A4.2); any other event for such a key fails safety_write_forbidden if the key is safety-critical and inference_forbidden otherwise. An inference event for any other key with inferable:false fails inference_forbidden.
Rejected suggestions must not repeatedly resurface: suppress identical (client,domain,key,canonical value digest) proposals for 90 days unless the person explicitly reopens the suggestion or supplies a new declaration. Evidence references are opaque pointers, not permission for the server to fetch arbitrary URLs. External evidence retrieval needs separate safe-fetch and owner consent rules.
A14.4 Separation of history and preference
Contributing viewing activity does not imply permission to read a person's other preferences. Another service may request reviewed preferences, raw history or both, with separate key selection. Derivations obey A4's recursive input-rights rule. An independently confirmed preference can be shared without history, while original source evidence remains protected.
Continuous connectors are reserved for 2.0; see the connectors reservation.
A14.5 Contribution and reciprocal portability
A contribution grant is bounded permission to submit proposals, not to read or overwrite the record. Version 1 HTTPS push has a strict event schema, authenticated source identity, stream namespace, idempotent event IDs, finite limits, correction/withdrawal rules and replay tombstones. A14 defines the full contract. No continuous subscription survives revocation.
Distinguish user-supplied preferences, activity, observations and inference. Review does not automatically create a declaration: the person confirms the exact statement, while provenance and protected evidence remain intact. A contributor cannot alter an independent declaration or learn who later reads its contribution.
A person can share reviewed preferences, raw history or both. Preferences do not automatically expose history. Derivations require permission for every actual input field and level; a separately confirmed declaration may be shared independently.
Portability requires bidirectional transfer for the categories claimed, preservation of meaning and temporal/provenance data, validation, unsupported-data reporting and tests. Exports do not transfer executable tokens, grants or private keys. Provider migration requires fresh provider/audience-valid consent. The old contributor does not learn the destination by default.
Checks: CONTRIB-01 to CONTRIB-03, INFER-01, CONSENT-01, TEMP-03, CORE-01.
References to other standards and projects describe intended technical alignment only and do not imply endorsement or partnership.