Understand project contribution and data records¶
Project work creates more than the current board or report. Some completed actions also produce contribution evidence: a record of the outcome, the people explicitly attributed to it and the supporting reference. This helps other platform capabilities trace an outcome back to project work. It is not, by itself, a score, an award or proof of individual productivity.
Availability: The project backend records the outcomes described here and participates in workspace export and deletion. This page explains that background behavior. It does not introduce a contribution dashboard, export button or deletion journey that has not been verified. Follow the intended task journeys in the execution, governance, repository and shared-delivery guides; their frontend and design limitations still apply.
What becomes contribution evidence¶
| Project outcome | People recorded | Meaning and limits |
|---|---|---|
| Deliverable accepted | The person associated with the acceptance event | The deliverable's accepted outcome, not every collaborator who helped produce it |
| Work item completed | The assigned performer when present; otherwise the person associated with completion | The recorded completion; it does not establish independently approved quality in every completion mode |
| Review completed | The reviewer, plus a different performer as a named participant | The review decision and a quality finding; a rejected review remains a reviewed outcome, not an approved deliverable |
| Milestone achieved | The person associated with the achievement | Achievement and its target date when available; the system does not create this contribution record when that person is missing |
| Dependency resolved | The dependent item's owner and explicitly named other resolvers | The recorded resolution and its proof; this does not itself complete the work item |
| Shared delivery recorded | The first named participant as the main person, with the remaining named participants | Explicit attribution to this shared result; team or project membership alone does not add everyone |
| Repository evidence accepted | The person accepting the evidence | Explicit acceptance with a supporting reference; import or attribution alone does not produce this contribution outcome |
The role recorded for an outcome describes that outcome. It does not grant product permissions, prove project ownership or establish how a later analytics calculation will credit the person. Shared delivery uses the submitted participant order to select its main person; do not assume that this person is necessarily the person who submitted the action.
There are separate records for work, review and acceptance because they answer different questions. A review can approve work that another person performed. A completed item can still have a separate deliverable awaiting acceptance. An imported build can support completion requirements without having a recorded evidence-acceptance decision. Read the underlying project facts before interpreting an aggregate result.
Interpret timing and quality carefully¶
The contribution record contains selected facts from the triggering action. It is not a timesheet or a complete reconstruction of work:
- Work-item timing can start at assignment, which may differ from when work actually began.
- Dependency duration runs from creation of the dependency relationship to its recorded resolution. It is not a measured total of the item's blocked periods.
- A review records its decision and finding, but its contribution record does not include how long the review took.
- These project contribution records do not supply expected or actual effort. A missing value is not zero effort.
- Completion and shared delivery can carry an accepted-quality label without an additional independent acceptance check when that record is created. Apply the underlying task's approval rules before interpreting that label.
The event time describes when the source outcome occurred. It does not prove when another product received or displayed it. A record can be saved while a downstream view is still catching up.
For managers and executives, use these records to investigate attribution, approvals and delivery exceptions. Do not turn event counts, elapsed time or a missing record into an unsupported performance comparison. Downstream eligibility, reconciliation, scoring and visibility have their own rules and are not established by the project producer alone.
When a record appears missing or inconsistent¶
The system keeps a record of the contribution evidence it prepared to share. Repeating the same recorded outcome is intended to avoid duplicates. Changed details for an already-recorded outcome can be rejected instead of replacing the original evidence. Some repeat completions, changed acceptances or multiple dependency resolutions therefore need investigation; repeating the business action is not a reliable repair method.
Background delivery checks can compare a day's recorded evidence and resend exact stored records when requested. This helps repair delivery of existing evidence. It does not create missing proof, add unnamed contributors or certify how another product interprets the record.
Before asking for help:
- Check the project's current item, review, deliverable or evidence record using the relevant guide.
- Identify which outcome you expected: completion, review, acceptance, dependency resolution or shared delivery.
- Keep the project and item references, approximate event time, expected people and visible result. Share sensitive evidence only through your organization's approved support channel.
- Ask support to compare the saved project fact with its publication and downstream processing status before advising a retry.
There is no verified general self-service control here for rewriting contribution history. A correction to current project work does not automatically establish that every earlier contribution record was corrected.
What a workspace export includes¶
The project portion of a workspace export includes project setup, execution groups and items, dependencies and reviews, milestones and criteria, deliverables, repository links and evidence attribution, formal-review links, saved report snapshots, local profile information, shared-delivery records and contribution publication records.
The export contains structured records. It is not a formatted project report or a complete platform backup. The project portion does not itself fetch external repository contents or collect document files from other services. Its completion does not mean all other products have completed their portions.
There is a known completeness limit: the separately stored list of participants in shared deliveries is not explicitly included in this export. Some attribution may appear in contribution records, but that is not a substitute for the complete participant list. An administrator should verify the required information before relying on an export for migration or recovery.
A record count counts exported rows across the included tables. It is not the number of projects, people, documents or files. An empty table does not explain whether no work existed, access prevented a read or a wider job failed; support should check the job result and authorized data scope.
What deletion means for project records¶
Workspace deletion is separate from completing, cancelling or placing a project on hold. Project lifecycle actions do not invoke this tenant-data deletion process.
The authorized workspace deletion process removes the included project data, including contribution records and saved report snapshots. This procedure offers no separate step to remove identities while retaining those records. It is configured to remove the participant list when its shared-delivery record is deleted; that behavior still needs verification in the deployed environment.
The completion response covers the project portion of the process. It does not certify deletion from external repositories, document stores, backups, operational logs or other products. Its deleted count does not separately enumerate all participant records removed through the shared-delivery relationship. A zero retained count is therefore not proof that no information exists anywhere in the platform.
Administrators should coordinate export, required retention and deletion through the platform's authorized process, and retain the job reference for support. This page does not claim a restore facility, retention period or legal deletion guarantee. Project-specific controls, complete export coverage and end-to-end delivery remain verification work.