---
title: Community Submissions
description: Review community contributions — annotation pins, identifications, oral histories, transcript corrections, and inline edits — approve suggested facts one by one, publish Community Notes, and keep editorial control of the record.
section: guides
order: 9
updated: 2026-07-13
verified: 2026-07-13
related: [guides/contributing-knowledge, guides/transcription-and-ocr, reference/roles-and-permissions, guides/working-with-artifacts, guides/ai-tools-and-provenance]
features: [community-contributions, memberships]
---

# Community Submissions

You'll learn how community contributions reach your institution, and how to review them from the **Community** queue without letting unreviewed changes become public records.

Community knowledge is often the difference between a silent photograph and a useful historical record. Preservated's submission model gives visitors a way to help while preserving editorial review, auditability, and institution scope.

## Who can contribute

Any signed-in Preservated user can send your institution a community note about an artifact — they do not need to be a member of your institution. Anonymous contributions are not accepted; every submission is tied to an account and reviewed before anything changes. Signed-in visitors can also propose structured field edits — directly inline or via **Suggest edit** — restricted to the community field set below. Reviewing is always restricted to **editors and admins**. The contributor's side of this flow, including image pin annotations and oral histories, is described in [Contributing Knowledge](/docs/en-US/guides/contributing-knowledge).

Transcript corrections are the one exception: they're off by default. Turn them on from **Admin → Settings → Community contributions**, choosing whether any signed-in user may propose one or only members of your institution.

## Inline edits by your own staff

Editors and admins can also use the same on-page pencil affordance to edit a field directly — no queue involved. That change applies immediately and lands in the audit log exactly like a save from the edit page, with full provenance. Viewer-role members and signed-out visitors never see the pencil; only a non-member or contributor-role member routes through the review queue below.

## What a contribution can contain

A community note arrives as a proposal, never an immediate edit (unless it's an inline edit by an editor/admin, above). It can carry:

- Freeform text — a memory, correction, or identification in the contributor's own words.
- A voice recording (up to 10 minutes) or an oral-history recording (up to 90 minutes, transcribed with speaker labels), preserved as an audio asset and transcribed automatically.
- A pinned region on the artifact image, or a pinned moment or stretch on an audio/video item's timeline (both are annotations), with an optional identification of a depicted person.
- AI-suggested field changes extracted from the text or transcript, each with a confidence score, a reason, and a verbatim quote as evidence. Annotation pins skip AI extraction — there's no transcript to extract from.

Contributors may only suggest changes to a restricted field set: title, description, date, places, creators, rights, type, and subject terms. Identifiers, visibility, and people links are never open to community suggestion.

:::info
The AI that reads contributions is advisory only. It proposes; it never writes to your catalog. Every suggestion waits for a reviewer's explicit decision.
:::

## The submission lifecycle

| Status | Meaning |
| --- | --- |
| Draft | The contributor is still working (or a voice note is still processing). |
| Pending review | Submitted and waiting for a reviewer. |
| Changes requested | Returned to the contributor with comments. |
| Approved | Accepted by a reviewer, ready to apply. |
| Applied | Accepted changes were written to the record. |
| Rejected | Declined, with a reason. |
| Withdrawn | The contributor pulled it back before a decision. (After acceptance, contributors instead remove the public display — the note is redacted and the archival original kept.) |

## Review contributions

Open **Admin → Community** to see the queue. It's the review queue for **every** submission to your institution — community notes, identifications, oral histories, and transcript corrections, but also suggested edits and inline-edit suggestions from visitors and members. It defaults to pending submissions; filter pills switch between statuses. Each row leads with an excerpt of what the contributor actually wrote, followed by the kind of contribution, the author, the target artifact, and — when the submission proposes field changes — how many.

Open a submission to review it in full: the contributor's note, the audio player and transcript for voice notes and oral histories, and their consent choices (public attribution opt-in, museum-only requests). Each AI suggestion appears as its own row — current value beside proposed value, confidence score, and the evidence quote with a timestamp into the recording. Check the suggestions you want to accept, and edit any proposed value inline before applying — an edited value is recorded as your edit, not the contributor's. Suggestions the contributor dropped before submitting arrive unchecked with a **Contributor dropped** badge (and their reason, if they gave one).

A contributor may submit before AI processing finishes (the dialog allows it when processing runs long) — in that case suggestions can appear on a pending submission shortly after it lands in the queue, without contributor keep/drop marks.

**Approve & apply selected** applies only the checked suggestions in one step. Each accepted change passes the same safety checks as any other edit: pinned fields are skipped and reported, stale values are detected, and every applied field records community provenance (who contributed it, through which submission) plus an audit-log entry. Suggestions you leave unchecked are recorded as skipped; nothing is applied silently.

You can also **Return with comments** to ask the contributor a question, or **Reject** with a reason. A separate **Reject as spam** is for junk rather than a good-faith contribution that didn't work out — it declines the submission and counts more heavily against the contributor's standing (below). Every decision — accepted, declined, changes requested, applied, or a comment — reaches the contributor as an in-app notification, and updates the submission timeline, which supports internal-only notes alongside contributor-visible comments.

### Contributor standing

Each submission shows the author's **standing** at your institution — **New**, **Established**, or **Trusted** — derived from their history of accepted, declined, and spam-flagged contributions here (standing is per-institution and never crosses between museums). The queue surfaces trusted contributors' pending submissions first, so a track record earns faster attention.

Standing is advisory. It **never** auto-applies anything — every change still waits for your explicit decision. Its only concrete effect is on limits: established and trusted contributors get proportionally higher daily contribution caps, so a proven helper isn't throttled like a first-time visitor. A single spam flag bars the trusted tier, so marking genuine junk as spam (rather than a plain rejection) keeps the perk meaningful.

### See who else agrees

When two or more contributions on the same artifact assert the same fact, the review page connects them. Each suggestion that others have echoed shows a **"N other contributor(s) said this"** badge, so corroboration is visible at a glance. An **Evidence** panel gathers everything supporting the submission in one place — the transcript quote and its timestamp, the pinned image region, other submissions on the same artifact, and any linked people.

For an artifact with several overlapping contributions, an **AI synthesis** panel can summarize where contributors **agree** (with a suggested combined value and a confidence score), where they **contradict** each other, and an overall confidence, followed by a short advisory summary. It's clearly labeled AI-generated and advisory — it reconciles what people said to help you decide; it never edits the record. Running it draws on your institution's AI credit wallet, the same as other AI tools, and needs at least two overlapping contributions before it's available.

### Reviewing an annotation pin

An **annotation** submission shows the contributor's pin in context. For an image pin, that's a preview of the image with the region outlined; for an audio/video pin, it's the recording's player with the pinned time range shown and a **Jump to pin** control so you can hear or watch exactly the moment being described. Approving it publishes the pin as an accepted **Community Note** of kind "annotation" — an image pin appears as a hover highlight over that part of the image, a timeline pin appears beneath the player as a marker you can seek to and a note that surfaces during playback — and either can be redacted or moved between public/museum-only like any other note.

When the contributor checked "This identifies a person," the submission is an **identification** instead, and you resolve who the pin refers to before approving:

- **Check for duplicates** against the name the contributor gave. Existing people that plausibly match are listed with a match tier and score — pick one to link to instead of creating a new record.
- If none match, approving creates a new **provisional** person with that name. Provisional people are invisible everywhere public (person pages, artifact credits, search) until a curator confirms them.
- If a detected face in the photo overlaps the pinned region, you can link the identification to that face — face links are offered only when a detected face actually overlaps the drawn region; otherwise the identification stays text-only.

A provisional person stays hidden until you **Activate** it — right after resolving the identification, or later from **Admin → People**, where provisional people carry a **Provisional** badge and a **Confirm** action. Linking to a new person does not make it public by itself; activating is a separate step.

If an identification is wrong, **Reject person** (beside Confirm, on the review page and in **Admin → People**) discards the provisional record: it's soft-deleted and stripped from every artifact that referenced it, and any detected-face link it held is detached. Rejecting asks for confirmation first, since it removes the person from those artifacts.

### Reviewing an oral history

Oral-history submissions show the diarized transcript in the same expandable panel used elsewhere in Preservated, with each speaker's turns labeled. AI-suggested facts extracted from the transcript are reviewed the same way as a voice note's — check, edit, or leave unchecked. Approving accepts the recording and transcript museum-only; publishing them to the artifact page's Oral History section is the deliberate acknowledged step described under [Publishing voice publicly](#publishing-voice-publicly).

### Reviewing a transcript correction

A **transcript correction** proposes fixing recognized text in a document. Contributors create them from the transcript editor's restricted **Suggest corrections** view, bundling one or more line fixes across the artifact's files into a single submission. The review page shows each proposed line for context with the corrected span highlighted, the proposed reading beside the original, the contributor's note, and a link to open the artifact in the **transcript editor** if you'd rather fix it yourself.

Approving writes the correction(s) straight to the document's transcript — there's no field changeset and no Community Note; it never appears on the public artifact page as attributed community content, it just corrects the text.

- **A single-line correction** approves as one line: approving applies it, or a stale check (someone else edited the line, or a fresh OCR run replaced the layer, since the correction was proposed) refuses the apply and shows a warning with the current reading instead of overwriting text the contributor never saw. Reject it or make the fix yourself in the transcript editor.
- **A batch of several lines** shows each proposed line as its own checkbox, grouped by file, so you can accept some and skip others. Lines are checked by default; any line whose text has changed since it was proposed — a live staleness check runs when you open the submission — starts **unchecked** with a warning, so a stale fix can't slip through by default. **Approve & apply selected (N)** applies only the checked lines: each shows its outcome (applied, stale, or failed) afterward, so a partial approval is easy to read at a glance. If every checked line turns out to be stale, the apply is refused rather than silently doing nothing; uncheck the stale ones (or refresh and re-check) and try again.

The transcript editor also shows a **pending corrections** count for any artifact with corrections waiting in the queue, linking straight to **Admin → Community**.

## Community Notes

Accepting a contribution can also publish it as a **Community Note** — a reviewed, attributed layer of community knowledge attached to the artifact, separate from your catalog fields. Notes come in three kinds — plain notes, annotation pins, oral histories — and each displays in its own place on the public artifact page: notes in a panel near the bottom, oral histories in their own section, annotation pins overlaid on the image. Notes from a voice or oral-history contribution carry an AI-transcription disclosure.

- Attribution is opt-in: the contributor's name appears publicly only if they chose that at consent time.
- A contributor's museum-only request always wins — such notes are never published publicly, regardless of the reviewer's choice. On these notes the **Publish** action is replaced by a consent notice, and the server refuses the transition even if requested directly.
- Notes the contributor allowed to be public can later be moved between public and museum-only, withdrawn, or **redacted**. Redaction removes the public text permanently while preserving the archival original (including audio and transcript) for scholarship, as disclosed at consent. Redacted, museum-only, and withdrawn notes never render publicly.
- Contributors can remove the public display of their own accepted contribution at any time from **Account → My Submissions**; the note is redacted the same way, with a timeline entry on the submission.

### Publishing voice publicly

Voice recordings get extra care before they play on a public page. Two gates apply:

- **Public playback is off by default.** A visitor's ordinary voice note never plays on public artifact pages until you turn on **Public voice notes** in **Admin → Settings → Community contributions**. With it off, an accepted voice note can still be published as text (its transcript), but the audio itself isn't served or played to the public — staff can always review it. (Oral histories are a separate, curated flow and aren't governed by this switch.)
- **A recording never publishes to public in one click.** Accepting a voice note or oral history publishes it museum-only first. Moving it to public is a deliberate step that opens an acknowledgement: you confirm the recording contains no other people's voices used without permission, no unverified claims about living people that could be defamatory, and no culturally restricted knowledge that shouldn't be public. All three must be checked before **Publish** proceeds, and the acknowledgement is recorded with your name and the time. Text-only notes publish in one click as before.

These gates turn the launch-readiness policy questions around public voice into concrete review steps; the institution still owns the underlying policy decisions before enabling public voice.

### Search visibility

Accepted **public** notes — including annotation and oral-history text — are indexed and findable through the same search visitors use, surfacing as a "Community note" snippet. **Museum-only** notes are indexed too, but only staff-tier searches see them. Redacted or withdrawn notes are removed from the index and are not findable by anyone.

## Costs and limits

Voice transcription (including live transcription while the contributor is recording), and AI suggestion extraction are billed to the institution's AI credit wallet — contributors never pay. Community processing has its own guardrails on top of your credit balance: a daily and monthly community spend ceiling per institution, per-user daily contribution limits (raised for established and trusted contributors — see [Contributor standing](#contributor-standing)), and recording caps (10 minutes for voice notes, 90 for oral histories). When a ceiling is reached, new contributions are still accepted but their AI processing is paused and reported on the submission, and live transcription stops being offered until the ceiling resets. A contributor's unfinished drafts count toward their daily limit until withdrawn.

:::note
When you invite community members to contribute, ask for evidence — "identified by donor's daughter, June 2026" is more useful than a bare name, and uncertainty should stay visible ("possibly Mary Collins" beats turning a guess into a fact). Submissions differ from AI suggestions in origin, but share the same review philosophy: proposed information becomes official only when a person with the right role accepts it.
:::

<!-- TODO screenshot: assets/guides/community-review-detail.webp
     Capture: Admin → Community → a pending voice-note submission showing the
     audio player, transcript, and per-suggestion checkboxes with confidence
     badges, 1440px wide, light theme. -->

<!-- TODO screenshot: assets/guides/community-review-identification.webp
     Capture: Admin → Community → a pending identification submission showing
     the image preview with the pinned region and overlapping detected
     face(s), plus the duplicate-candidate list and "Create provisional
     person" option, 1440px wide, light theme. -->

<!-- TODO screenshot: assets/guides/community-review-transcript-correction.webp
     Capture: Admin → Community → a pending transcript-correction submission
     showing the line context with the corrected span highlighted, the
     before/after text, and the "Open in Transcript Editor" link, 1440px
     wide, light theme. -->
