← Framework

Stage 2 · Capture

Identity and Authority Evidence

How to preserve evidence of who controlled a record, who acted, and who had authority to create, hold, evidence, approve, publish, or rely on it.

creatorsbusinessesresearchersadvisersorganisationsinstitutions

Identity and Authority Evidence

Identity and authority evidence helps show who was involved with a record and whether they had the right to act.

It is not enough to know that a file, message, dataset, approval, upload, publication, or decision exists. In many situations, it also matters who created it, who controlled it, who approved it, who submitted it, who had access to it, and who had authority to make a claim from it.

The purpose of this guide is to help users preserve identity and authority context before records are challenged.

Identity and authority evidence is especially important for organisations, business records, authorship claims, research contribution, AI training data, synthetic media, cyber incidents, contract records, public statements, and any workflow involving delegated responsibility.

Quick Read

  • Identity evidence helps show who was connected to a record.
  • Authority evidence helps show whether that person or organisation had the right, role, permission, or control needed to act.
  • Identity and authority evidence does not automatically prove truth, legality, ownership, authorship, or permission by itself.

What this means

Identity evidence concerns the person, account, organisation, role, device, system, or process connected to a record.

Authority evidence concerns whether that person, account, organisation, role, or system was entitled to do what was done.

For example, a record may show that an employee approved a decision, but not whether they had authority to approve it. A file may be uploaded from an account, but the account may not prove who controlled it at the time. A dataset may be submitted by a supplier, but the supplier may not have preserved permission evidence. A public statement may be made by an organisation, but the internal authority behind that statement may be unclear.

Identity answers: who was involved?

Authority answers: were they entitled to act?

Why it matters

Many evidence problems are not caused by missing files. They are caused by unclear responsibility.

A record may exist, but the person behind it may be disputed. An account may have been shared. A role may have changed. An approval may have been informal. A contractor may have acted outside scope. A team may have relied on material without clear permission. A platform account may not show who controlled it at the relevant time.

These gaps matter because evidence often depends on human or organisational authority.

If authority is unclear, later claims can become weak, even where the file itself is preserved.

Strong identity and authority evidence helps explain who acted, in what capacity, under what permission, and with what responsibility.

What strong identity and authority evidence should include

A stronger identity and authority evidence position usually includes:

  • The relevant person or organisation — who created, supplied, approved, submitted, published, controlled, or relied on the record.
  • The role or capacity — whether they acted as an individual, employee, contractor, supplier, agent, officer, researcher, creator, administrator, or authorised representative.
  • The account or system context — what account, device, platform, service, workspace, repository, or system was used.
  • The authority basis — the contract, permission, role, policy, instruction, delegation, licence, approval, or right relied on.
  • The action taken — what the person, account, organisation, or system actually did.
  • The timing context — when the authority existed and when the action happened.
  • The access context — who had access to the record, account, workspace, or system.
  • The approval context — who reviewed, approved, escalated, rejected, or authorised the action.
  • The supporting records — messages, policies, contracts, access logs, approvals, identity checks, assignment records, or audit trails.
  • Claim boundaries — what the identity and authority evidence supports and what it does not support.

The higher the stakes, the more important the authority basis becomes.

Common weak points

Identity and authority evidence is usually weak when:

  • an account is treated as proof of a person without more context
  • shared logins are used
  • access records are incomplete
  • role changes are not documented
  • approvals are informal or missing
  • a contractor, supplier, employee, or agent acts without clear scope
  • records are submitted by someone whose authority is unclear
  • the evidence does not show who controlled the file or account at the relevant time
  • organisational responsibility is assumed rather than documented
  • AI-generated or AI-assisted outputs are stored without human responsibility records
  • datasets are used without supplier authority or permission context
  • public claims are made without showing who authorised them
  • the authority claim says more than the records support

These weaknesses can make an otherwise useful record difficult to rely on.

How to apply this yourself

For each important record, create an identity and authority note.

Ask:

  • Who created, supplied, submitted, approved, published, controlled, or relied on the record?
  • In what role or capacity were they acting?
  • What account, system, device, workspace, or platform was used?
  • Who had access at the relevant time?
  • What authority, permission, contract, role, instruction, licence, or approval allowed the action?
  • When did that authority exist?
  • What action was actually taken?
  • What supporting records show identity, access, authority, or approval?
  • Can someone else understand why the person or organisation had the right to act?
  • What identity or authority claim cannot be supported?

Then preserve the supporting records with the main evidence record.

Do not assume that an account name, email address, file owner field, or platform profile proves authority by itself.

What this does not prove

Identity and authority evidence does not automatically prove:

  • ownership
  • authorship
  • copyright
  • permission
  • legality
  • originality
  • accuracy
  • authenticity
  • full account control
  • full organisational approval
  • absence of misuse
  • absence of dispute
  • that EviWrite has verified the identity or authority

Identity and authority evidence helps show who was connected to a record and what authority may have supported their action. It does not decide every claim about the record.

Framework-aligned claim boundary

A person or organisation may use this guide as part of EviWrite Framework alignment if they apply the guidance honestly and avoid implying EviWrite involvement.

Acceptable wording may include:

“We use the EviWrite Framework to preserve identity and authority evidence for important records.”

It must not be used to imply:

  • EviWrite has verified identity
  • EviWrite has confirmed authority
  • EviWrite has approved the person, organisation, or claim
  • the record is EviWrite-backed
  • the record is EviWrite-certified
  • the record carries the controlled ⓔ mark
  • EviWrite has endorsed the organisation’s authority process

Framework-aligned means public guidance was followed.

EviWrite-backed means the record was created through EviWrite or an authorised evidencing channel.

Related checklist

Use the Identity and Authority Evidence Checklist to check whether the person, role, account, permission, access, approval, and authority basis behind an important record have been preserved clearly.

This guide is public evidence-readiness guidance. It does not mean EviWrite has verified, certified, approved, anchored, or backed any record.

Return to Framework map