Family Archive Integrity Standard — draft for review

Status, scope, and intended use

Draft 0.1, September 28, 2026. This proposal is published by Pinkas for discussion with families, archivists, genealogists, rabbis, and preservation practitioners. No external reviewer or organization has endorsed it. The scope is a private digital family archive, including uploaded originals, descriptions, derived material, access, retrieval, and export.

Use the checks below when evaluating an archive or designing a family workflow. A service should not claim conformance simply because it publishes these principles. Conformance would require dated evidence for each check, documented exceptions, and independent review.

1. Preserve originals separately

Proposed requirement: an edited image, transcript, translation, or generated output must remain distinguishable from the source. Ordinary editing must not silently overwrite the received original.

Evidence to request: upload a sample, produce an edited version, and download both. Compare the original file with the received copy, record the result, and document the effect of deletion and retention settings. Preserving an original does not mean that lawful deletion is impossible.

2. Retain the source of a claim

Proposed requirement: a description or family-history assertion should support an attributable source, including a document reference, an identified interview, or an explicitly labeled recollection. Unknown provenance must remain visible.

Evidence to request: select a claim from a person, photograph, or story; trace it to the original item or contributor; then inspect whether that source survives an export. A claim with no source should not become 'verified' merely because it has been copied several times.

3. Keep uncertainty and AI assistance visible

Proposed requirement: a generated transcript, suggested identity, inferred relationship, or summary must not silently acquire the status of a confirmed fact. A reviewer should be able to accept, correct, reject, or leave a suggestion unresolved.

Evidence to request: introduce a deliberate ambiguity into a test recording or identification. Confirm that the suggestion remains distinguishable before review and that any exported or printed account preserves relevant uncertainty. Record who reviewed the result and the reason for a correction where supported.

4. Authorize before retrieval

Proposed requirement: the requester's current access should be checked before returning archive material, including search results, generated answers, thumbnails, recordings, and exports. Knowing an item identifier must not grant access.

Evidence to request: test the same item as an allowed member, a restricted member, and an unauthenticated visitor. Repeat after access is revoked. The test must include derived material and retrieval systems, not only the normal item screen.

5. Make sharing intentional

Proposed requirement: private material should remain within its intended audience until an authorized person chooses a wider audience. A demonstration, referral, or marketing feature must not publish private content as a side effect.

Evidence to request: inspect a newly added item, a share action, and a downloaded artifact. Check whether the user can understand the recipients before sharing and whether a withdrawal stops future service access. Explain that downloaded copies cannot be recalled by changing a service permission.

6. Provide usable exits

Proposed requirement: authorized people should be able to retrieve original media and readable descriptive data with stable connections between them. The service should explain who can request a complete export and what is excluded.

Evidence to request: open a representative export outside the service. Locate a person, an original image, a caption, a source, and a recording. Check file completeness and explain any unsupported relationships, access limits, temporary links, or missing data. Keep a separate secure copy and periodically test readability.

7. Plan stewardship and deletion

Proposed requirement: families should understand who maintains access, how a successor is appointed, how deletion operates, and what remains in backups. A general promise of permanence is not a substitute for documented operational limits.

Evidence to request: review administrator succession, account recovery, export permissions, retention settings, and deletion behavior using test material. Record unresolved risks and a family contact who can explain the plan to the next steward.

What Pinkas currently documents

Pinkas's published archive principles describe keeping crops, transcripts, and printable files separate from original uploads, retaining sources, and reviewing suggestions. Its export documentation describes permission-scoped family exports, separate data-trustee access for a complete archive, and expiring download links.

These are documented product behaviors, not evidence that all seven proposed requirements have passed an independent audit. Availability and details remain governed by the current product documentation, privacy policy, and offer. This draft makes no guarantee of uninterrupted access or indefinite preservation.

Check current product documentation

How to review this draft

Send the clause number, a concrete failure example, and a suggested test or wording change. Identify whether you are commenting as a family user, preservation practitioner, genealogist, religious adviser, or software reviewer. Do not include private family records in a public review.

A future revision should publish its changes, reviewer permissions, unresolved objections, and the evidence required for any conformance claim. Names should be credited only with permission. Until that work exists, describe this as a proposed standard.

Contribute a review