Goal

Use written standards and policy baselines so naming, access, rights, and publication decisions stay consistent from capture through preservation and release.

1) Open the policy files you actually maintain

These policies work best when they are written as living files rather than abstract ideas. Switch between the workflow standard and registry view, then hover or click the highlighted parts.

Policy files in practice

Workflow standard

workflow_standards.txt

Repository-wide rules that projects should follow

Documentation/workflow_standards.txt
Collection manager or project lead
A-Z, a-z, 0-9, underscore only
<Collection>_<4digitID>_<ShortLabel>
Projects are temporary; Preservation is long-term
<ObjectID>_<asset>_v##_pres.<ext>
Access and print files never replace masters
No ambiguous names like final.obj; no renaming after DOI assignment

File location

Keeping this in Documentation/ makes the rules visible at repository level instead of burying them in one project folder.

Owner

A policy without a maintainer drifts fast. Name who updates the standard and when it should be reviewed.

Character rules

Simple character rules keep filenames script-friendly and reduce broken paths across systems.

Object naming

This is the baseline identity rule. It helps naming stay stable across metadata, files, folders, and repository records.

Workspace policy

Policy should explicitly separate active project space from long-term preservation space so access copies and working files do not overrun the archive.

Preservation master rule

Define how master files are named and retained so they stay distinct from access and print derivatives.

Derivative rules

Access and print derivatives need their own rules because they often include optimization or repair choices that should be documented separately.

Do not rules

Negative rules are useful because they block risky shortcuts before they become habits.

{
  "policy": {
    "": "",
    "": "",
    "": "",
    "": ""
  },
  "publication": {
    "": "none",
    "": null,
    "": null
  }
}

access_level

Public, internal, restricted, or embargoed access needs to be explicit so technical sharing does not outrun governance.

rights

Rights statements document who owns the digital files, which is not always the same as who owns the physical object.

license

Licenses clarify what reuse is permitted once access is granted.

attribution

This field records how credit should be given when people reuse or cite the asset.

doi_status

DOI status helps the team track whether publication is planned, reserved, or already released.

doi_value

Store the actual DOI once assigned so local records and public citation stay connected.

landing_page

The landing page is where users should arrive, not a fragile direct file link that may change later.

2) Policy questions to resolve before release

Who controls access?

Decide whether the object should be public, internal, embargoed, or restricted before any upload workflow begins.

Who owns what?

Separate physical object ownership, digital file copyright, and repository stewardship responsibilities.

What reuse is allowed?

Choose the license and attribution expectation that match the intended audience and ethical constraints.

When does DOI publication happen?

Define whether DOIs are planned, reserved, or published, and make sure the landing page is ready when status changes.

3) Final review checks before release

Naming and folders

Confirm the files still follow the standard

Release is the wrong moment to discover a repository naming mismatch.
  1. Confirm object filenames and folder names match Documentation/workflow_standards.txt.
  2. Confirm preservation packages are in repository preservation storage and not only in project working folders.

Rights and access

Make sure the policy values agree with the object record

Rights drift between files and metadata causes confusion later.
  1. Confirm policy values in project_registry.json match object metadata rights and access fields.
  2. Confirm license and attribution language match the intended release.

Publication

Check DOI and landing page details

Persistent identifiers only help when their local records are current.
  1. Confirm DOI status and publication landing page fields are current before public release.
  2. Confirm repository metadata, local metadata, and policy statements are synchronized.