Projects and provenance

An organization owns repository projects. Each project has a name, code, operating dates, active value and policy reference. The administrator maintains the project record so operators can assign content to the right collection. People also belong to an organization, giving the item owner and reviewer a consistent operational context. A content item linked to the wrong project can be reviewed under the wrong policy, so project selection deserves attention at intake.

Source mappings describe how incoming fields map to target fields. A mapping records its version, field names and types, transform rule and effective date against a project definition. These records are useful when content arrives from a source system with a different identifier or title format. Keep the original source reference with the requirement or file so a later reviewer can trace the transformed value back to its origin.

• Projects define collections. The organization and policy reference identify the context for each item.
• Mappings name the transformation. Source and target fields can be checked against the intended project version.
• History records transitions. The item’s actor, source revision, reason and from/to states support later review.

Choose stable organization and project codes before import. Confirm each project’s start and end dates, active value and policy reference. Assign people to the right organization. If a source feed is involved, agree field types, transform rules and the effective date for each mapping version. Test a sample record with a changed title or source identifier before loading a whole collection.

Decide who may maintain project definitions. The administrator can enter Projects; the operator works with content and evidence. A policy change should be communicated to reviewers before a new revision is submitted. Preserve old mapping versions where they explain previously processed source payloads. The item’s state history should be read with its revision and operation key when investigating a transition.

An organization opens a new project for a digitized collection. The administrator records its project code, dates and policy reference. A source feed uses a different field name for the source identifier, so the team agrees a mapping version and transform rule during setup. An operator enters a sample content item and confirms that its project, organization and owner resolve correctly. The reviewer opens the item, sees its requirement and evidence references, and applies the right policy. If the item later changes state, the history links the transition to its actor and revision.

• Project schedule — Active projects with their operating dates and organization.
• Content intake board — Items in the configured project and their working status.
• Runs requiring reconciliation — Outcomes that need the project’s mapping and source context.

Content intake to decision applies the project context. Decision to delivery uses the source and result references.