Authorisation scope record

What this worksheet records

An authorisation scope record should state the party giving permission, the party receiving it and the exact actions covered. Define the project, records or assets involved, with exclusions recorded as clearly as permitted actions. Effective and end dates matter for future use, but they should be taken from an actual attributable grant. A broadly worded local role such as “partner” does not establish permission to see every client, edit protected artwork or make commitments for another provider.

Complete and review it

Check the scope before each consequential action, including sharing files, issuing decisions or preparing a public story. When permission changes, use the commissioned system or agreed process to apply revocation and test access paths. Preserve relevant history and accepted obligations according to the actual agreement rather than assuming every record must disappear. If the relationship between expiry, revocation and continuing fulfilment is unclear, obtain a job-specific interpretation from the responsible parties and appropriate advisers.

Field definitions

• scope_record_id: A stable identifier for this scope record, used to connect related rows without merging unrelated records.
• granting_party: The actual party for granting party, with its responsibility or rights source identified; do not substitute the platform brand.
• authorised_party: The actual party for authorised party, with its responsibility or rights source identified; do not substitute the platform brand.
• project_id: A stable identifier for this project, used to connect related rows without merging unrelated records.
• record_or_asset_scope: The actual boundary of record or asset scope for this row; name inclusions and exclusions instead of implying unlimited applicability or access.
• permitted_action: The actual permitted action relevant to this row’s declared purpose. Record the source or unresolved question where it is not confirmed.
• excluded_action: The actual excluded action relevant to this row’s declared purpose. Record the source or unresolved question where it is not confirmed.
• effective_date: The actual effective date, with date format or period meaning explicit; distinguish requested, planned, confirmed and observed values.
• end_date: The actual end date, with date format or period meaning explicit; distinguish requested, planned, confirmed and observed values.
• condition: The observed condition and relevant inspection scope; this field supplies no competent clearance by itself.
• revocation_route: The actual revocation route relevant to this row’s declared purpose. Record the source or unresolved question where it is not confirmed.
• accepted_obligation_reference: The actual attributable source for accepted obligation reference; a reference is not evidence that a decision was authenticated or its content verified.
• evidence_reference: The actual attributable source for evidence reference; a reference is not evidence that a decision was authenticated or its content verified.
• review_owner: The named person or agreed role responsible for review owner; confirm its real scope rather than assuming authority from a typed name.

Prepare a deliberate export

This record may contain sensitive permission and agreement references. Share its relevant scope, never credentials or private keys. Editing a CSV cannot enforce grants, revoke live access or resolve legal interpretation of an agreement.

Take it to the next job

• Identify exact records, actions, exclusions and responsible parties.
• Use attributable grants rather than assumed platform roles.
• Review expiry and revocation separately from continuing obligations.