Authority, Independence and Scope

Effective date: 22 July 2026
Last updated: 22 July 2026

A separate record before release

EviWrite creates and maintains a controlled evidence record of digital work before it is shared, pitched, submitted, published or released.

For supported hash-only records, the original file does not need to be uploaded to EviWrite. A cryptographic fingerprint and permitted record information are submitted instead. EviWrite records the evidence event under the applicable version of the EviWrite Evidence Standard, applies an EviWrite Official Timestamp and, where included in the record type, creates an external blockchain anchor.

The resulting record can be checked through EviWrite's public verification service. Where the record provides the necessary external-anchor data and proof, that anchor can also be checked independently of EviWrite's internal database.

EviWrite's authority is the authority to create, govern and verify records under the EviWrite Evidence Standard. Its independence is independence from the claimant in the recording and assessment of those records. Neither claim means that EviWrite is a government body, regulator, court or copyright office. EviWrite preserves and reports evidence; it does not decide the legal dispute for which that evidence may later be used.

An EviWrite record does not, by itself, prove authorship, ownership, originality or infringement. Its legal effect depends on the individual record, applicable law, surrounding evidence and the authority deciding the question.

Before it leaves your hands, make the record.

Make the record
Verify an E-mark

---

What EviWrite is - and what it is not

EviWrite is

• The private operator and governing body of the EviWrite Evidence Standard.
• A separate recordkeeper for evidence submitted by claimants.
• A creator and custodian of controlled digital evidence records.
• An operator of technical fingerprinting, timestamping, anchoring and verification processes within its published scope.
• A source of authoritative information about the contents and current status of its own records.

EviWrite is not

• A government body.
• A regulator.
• A court or tribunal.
• A copyright office.
• A statutory registration authority.
• A law firm.
• An accreditation body.
• An automatic verifier of authorship or ownership.
• A substitute for legal advice, statutory registration or judicial determination.

No government appointment, statutory status, accreditation or third-party endorsement is implied unless an individual statement expressly identifies it.

---

Why EviWrite exists

Copyright may be automatic. The evidence record is not.

In the United Kingdom, copyright generally arises automatically. There is no public or government register of copyright and no registration formality is required merely to obtain copyright protection.

That does not eliminate the need for evidence.

A later dispute may require evidence concerning:

• What existed.
• When it existed.
• Which version existed at a particular time.
• How a work developed.
• What information was associated with it.
• Who made the relevant claim.
• Whether a file presented later is identical to one recorded earlier.
• Whether an evidential record has changed since it was created.

EviWrite does not create or register copyright. It creates a structured record that may support factual questions concerning a work, its chronology, its recorded versions and the information associated with it.

Where a jurisdiction provides an official registration system carrying separate legal or statutory benefits, an EviWrite record is complementary evidence. It is not represented as a replacement for that registration.

The weight or admissibility of an EviWrite record is not uniform across every country or proceeding. It depends on applicable law, the reliability of the process, the contents of the individual record, competing evidence and the decision-maker considering it.

---

What kind of authority EviWrite holds

Authority over the EviWrite Evidence Standard and its records

EviWrite creates, maintains and verifies records under the privately governed EviWrite Evidence Standard.

Within that defined scope, EviWrite has authority to:

• Define the requirements of the EviWrite Evidence Standard.
• Publish and maintain versions of that standard.
• Accept evidence submissions under the applicable version.
• Create and maintain evidence records under defined controls.
• Determine whether a record satisfies the technical and procedural requirements applicable to its record type.
• Classify information according to its source and verification status.
• Apply and report an EviWrite Official Timestamp.
• Record external anchoring and technical-validation results.
• Maintain the public verification service and E-mark.
• Correct, supersede, limit, suspend or revoke records under governed procedures.
• State what EviWrite's systems recorded.
• State the current status of an EviWrite record.
• Explain what a particular record does and does not support.

Within this limited scope, EviWrite is the primary authority on the contents and status of an EviWrite evidence record.

EviWrite does not determine:

• Legal authorship.
• Copyright ownership.
• Originality.
• Infringement.
• Contractual entitlement.
• Liability.
• Damages.
• Admissibility in a particular proceeding.
• The weight a court or other decision-maker will give the evidence.
• The final outcome of a dispute.

EviWrite provides and explains the record. It does not appoint itself the judge.

---

Where EviWrite's authority comes from

EviWrite does not claim authority merely because digital creation evidence lacks a single universal regulator.

An unoccupied institutional space creates an opportunity. It does not, by itself, create legitimacy.

EviWrite's authority within its own defined scope rests on five connected foundations:

1. Relevant institutional and technical competence
2. A published and consistently applied evidence standard
3. Infrastructure designed to preserve and reproduce the record
4. Separate recording and independently inspectable external evidence mechanisms
5. Clear limitations on what EviWrite will claim

Authority is not created by a badge, a blockchain transaction or a marketing statement.

It is demonstrated through disciplined methods, transparent boundaries, governed records and evidence capable of being scrutinised.

---

The authority behind the standard

More than 50 years in directly employed and contracted professional roles

EviWrite was founded by professionals who have collectively completed more than 50 years in directly employed and contracted professional roles serving Big Four professional-services firms, government programmes, major global financial institutions and other highly controlled enterprise environments.

This was sustained technical, operational and governance responsibility - not indirect association, occasional contact or peripheral exposure to those organisations.

Their work has included responsibility for:

• Designing and architecting resilient and redundant enterprise infrastructure.
• Storage-area networks and enterprise block-storage platforms.
• High-availability data services.
• Datacentre and cross-site architecture.
• Geographically separated replication.
• WORM, immutable and offline-storage strategies.
• Backup, restoration and disaster-recovery architecture.
• Business-continuity and service-resilience planning.
• Infrastructure designed against five-nines-class availability objectives.
• Controlled infrastructure and application change.
• Access control and segregation of duties.
• Audit trails and reviewable technical records.
• Control design, operation, testing and evidence production.
• Audit and regulatory readiness.
• Work supporting Sarbanes-Oxley reporting and control obligations.
• Recovery planning for infrastructure failure, operational error and cyber incidents.

That accumulated service informs two connected parts of EviWrite:

• The Evidence Standard, which defines what must be recorded, classified and verified.
• The supporting architecture, which determines whether records can remain available, traceable, recoverable and resistant to undetected inconsistency.

An evidence standard is only as credible as the systems that create, preserve and reproduce its records.

The founders' prior service does not imply that any former employer, government body, financial institution or professional-services firm sponsors, approves or endorses EviWrite.

Those organisations are not presented as the source of EviWrite's authority. The founders' service describes the competence brought into EviWrite. EviWrite remains responsible for substantiating the quality and operation of its own standard, controls and infrastructure.

---

Evidence supported by resilient systems

The record must survive more than normal operation

Evidence is of limited value if it depends on fragile infrastructure, a single uncontrolled copy, an untested backup or an administrator's unrecorded ability to alter history.

EviWrite applies defined infrastructure and operational controls intended to support:

• Redundancy.
• Fault isolation.
• Durable storage.
• Controlled replication.
• Recoverable backups.
• Restoration.
• Disaster recovery.
• Restricted administrative access.
• Segregation of duties.
• Controlled change.
• Audit logging.
• Monitoring and alerting.
• Preservation of material record states.
• Detection of inconsistent or unauthorised changes.
• Reduction of avoidable single points of failure.

The controls currently implemented, their scope, their limitations and the dates of relevant tests are identified in EviWrite's current Technical Scope and Assurance Register where published.

EviWrite does not claim that prior work on systems designed against five-nines-class objectives means that EviWrite itself has continuously achieved 99.999% measured availability.

Any published availability, recovery or resilience result must identify:

• What was measured.
• The measurement period.
• The systems included.
• Material exclusions.
• The result achieved.

EviWrite does not rely on descriptions such as "military-grade," "unbreakable," "failure-proof" or "impossible to alter."

Its claims are limited to controls that are implemented, documented and capable of substantiation.

---

Independence from the claimant

The claimant is not the sole creator and custodian of the record

A claimant can save a file, alter metadata, create a screenshot, write a date on a document or maintain a private internal database.

Those materials may have evidential value, but the claimant remains their creator, custodian and presenter.

EviWrite creates separation between the person making the claim and the system recording the evidence event.

The claimant may provide:

• A file fingerprint.
• Identity or account information.
• A title or description.
• Claimed authorship or ownership information.
• Contextual metadata.
• Statements concerning the work.
• Related files, drafts or versions.

EviWrite separately performs the processes applicable to the selected record type, which may include:

• Applying the relevant Evidence Standard.
• Recording the submission event.
• Applying an EviWrite Official Timestamp.
• Recording system-generated facts.
• Preserving supported metadata or provenance state.
• Performing stated technical validation.
• Creating an external anchor.
• Maintaining the resulting evidence record.
• Providing a public verification route.
• Preserving correction and status history.

The EviWrite process does not provide the claimant with a mechanism to alter the recorded timestamp or silently replace the original fingerprint of a completed record.

Where a correction is permitted, the change is handled under the applicable correction or supersession procedure. A correction does not silently erase the prior evidential history.

Independence in four dimensions

Separation of record

The claimant does not retain sole custody or control of the completed EviWrite record.

Separation of commercial payment from record state

Payment purchases access to the service.

It does not permit the claimant to alter the recorded fingerprint, EviWrite Official Timestamp, technical-validation result or record status outside the applicable governed procedure.

Procedural impartiality

The same applicable record requirements are used regardless of the claimant's identity, prominence, account value, commercial importance or preferred conclusion.

Separate verification

A third party does not have to rely solely on a certificate, screenshot or database output supplied by the claimant.

The record can be checked through EviWrite's public verification service. Where an external anchor and the necessary verification information are supplied, that anchor can be checked independently of EviWrite's internal database.

The exact boundary of independence

EviWrite is independent from the claimant for the purposes of recording and assessing the evidence event.

EviWrite does not claim to be independent of:

• The EviWrite Evidence Standard, which EviWrite creates and governs.
• Its own infrastructure.
• Its legal ownership or commercial interests.
• Related companies or submission platforms where common ownership exists.

Where a related EviWrite company or platform facilitates a submission, that relationship is not disguised.

A submission platform may assist the claimant in creating and transmitting the evidence submission. The EviWrite evidence function separately controls the applicable standard, technical record status and any review performed under that standard.

No claim of corporate independence is made where common ownership exists.

No claim of independent third-party accreditation is made unless an applicable accreditation has actually been obtained and is expressly identified.

---

Review and assessment status

Not every EviWrite record receives the same type of processing.

An individual record may involve one or more of the following:

Automated record creation

The system receives permitted evidence data and creates a record according to predefined rules.

Automated technical validation

The system checks technical characteristics such as data format, cryptographic bindings, signatures, fingerprints, timestamps or anchor status.

Administrative review

An authorised person reviews record administration, process completion or a stated exception.

Substantive evidential review

An authorised reviewer assesses a defined evidential question under an identified procedure.

Reconsideration or appeal

A prior administrative or substantive decision is reviewed under a governed process.

The individual record should identify which of these processes occurred.

The words review, assessment, finding and determination are not used to imply human or expert consideration where the result was produced solely through automated processing.

---

How an EviWrite record is created

1. Hash-only recording for supported records

For supported record types, the file fingerprint is calculated locally on the user's device.

The original file does not need to be uploaded merely to create that fingerprint. The resulting cryptographic digest and the permitted record information are submitted to EviWrite.

A secure cryptographic hash maps digital data to a fixed-length digest. The digest can be used to determine whether data presented later has changed from the data used to create the original digest.

A later file producing the same supported cryptographic fingerprint provides strong technical support that the later file is identical at the byte level to the file fingerprinted earlier.

What a basic hash-only submission establishes

Unless an individual record includes a separate proof-of-possession control, a basic hash-only workflow establishes that:

• A particular digest was submitted.
• Particular associated information was submitted.
• The submission was associated with the identified account, session or process.
• EviWrite recorded that event at the stated time.

A basic hash-only submission does not necessarily establish that the claimant possessed the underlying file at that moment. A digest might be generated from another person's file, obtained from a separate source or submitted without the underlying file being retained.

The fingerprint also does not, by itself, establish:

• Who created the file.
• Who owns it.
• Whether it is original.
• Whether its contents are true.
• Whether associated metadata is accurate.
• Whether an identical file existed elsewhere at an earlier time.

The fingerprint identifies exact file data. The wider record supplies the stated context.

Hash-only is not the same as anonymous

Avoiding file upload reduces the disclosure of the underlying content. It does not automatically make the record anonymous.

Depending on the record type, EviWrite may still process:

• The file fingerprint.
• Filename or file-type information.
• File size.
• Declared metadata.
• Account information.
• IP address or security telemetry.
• Transactional and verification data.

A cryptographic file fingerprint may also be compared with candidate files by a party that already possesses those files.

The exact information collected, retained and displayed is governed by the applicable record type, Privacy Notice and public-disclosure settings.

Hash-only for supported records. The original file need not be uploaded.

2. EviWrite Official Timestamp

An EviWrite Official Timestamp is the timestamp attached to an EviWrite evidence record through the timestamp process designated by the applicable version of the EviWrite Evidence Standard.

It is EviWrite's designated record timestamp.

The term does not mean that the timestamp is government-issued, a qualified electronic timestamp or a timestamp carrying a particular statutory status unless the individual record expressly states that status.

An EviWrite Official Timestamp records when the relevant evidence data entered the designated EviWrite timestamp process.

It may support the statement that the recorded fingerprint or evidence data existed no later than the time shown.

It does not automatically establish:

• The original creation time of the work.
• The first time the work ever existed.
• The identity of the creator.
• Ownership of the work.
• The truth of associated statements.

Where an external timestamp provider is used, the record may identify:

• The provider.
• The timestamp type.
• The time reference.
• The validation result.
• Relevant certificate or trust information.
• Limitations affecting reliance.

WIPO previously operated WIPO PROOF, which created date-and-time-stamped digital fingerprints without requiring WIPO to retain the original files. WIPO discontinued creation of new WIPO PROOF tokens in 2022, while stating that existing tokens remain capable of verification.

That history supports the recognised method of recording a timestamped digital fingerprint. It does not mean that WIPO approves, certifies or endorses EviWrite.

3. External blockchain anchoring

Where included in the selected record type, EviWrite anchors a cryptographic representation of the evidence record to an external blockchain.

The private work itself is not published to the blockchain.

An external anchor can provide:

• An integrity reference outside EviWrite's primary database.
• Evidence that the anchored representation existed by the relevant blockchain event.
• An externally inspectable chronological reference.
• Detection of inconsistency between a later EviWrite record representation and its earlier anchor.
• Reduced reliance on EviWrite's internal database alone.

Blockchain does not independently determine whether claimant-provided information is true.

Its role within an EviWrite record is integrity and chronology - not authorship, ownership or legal judgment.

EviWrite uses descriptions such as:

• Tamper-evident
• Tamper-resistant
• Externally anchored
• Externally inspectable

EviWrite does not describe blockchain evidence as:

• Tamper-proof.
• Impossible to alter.
• Proof of legal ownership.
• Guaranteed truth.
• Legally conclusive.

When an anchor is independently verifiable

An external anchor is described as independently verifiable only where the relying party is given enough information to perform the verification without relying solely on an unexplained EviWrite result.

Depending on the anchoring method, this may include:

• The blockchain and network.
• Transaction identifier.
• Anchored digest.
• Hash algorithm.
• Record-representation or canonicalisation method.
• Merkle root and inclusion proof where records are batched.
• Confirmation status.
• Mapping between the EviWrite record and anchored value.
• Verification instructions.

Where this information is not provided, the record is not described as independently verifiable merely because an EviWrite webpage displays an anchor status.

4. Public verification through the E-mark

The E-mark is a public verification indicator linked to an EviWrite record.

It enables a relying party to check the current record status through EviWrite rather than relying solely on material supplied by the claimant.

Depending on the record's disclosure scope, the public verification page may display:

• The record identifier.
• Current record status.
• Applicable Evidence Standard version.
• EviWrite Official Timestamp.
• File-verification instructions.
• External-anchor status.
• Supported provenance or credential status.
• Correction, limitation, supersession, suspension or revocation information.
• The scope of what has and has not been verified.

The public page does not need to disclose:

• The work itself.
• The contents of the file.
• Private claimant information.
• Confidential descriptive information.
• Data from which the original file can be reconstructed.

The E-mark is publicly checkable through EviWrite.

It is not described as independent third-party verification of EviWrite itself.

Where an external anchor can be independently checked, that separate capability is stated on the individual record.

What the E-mark does not mean

The E-mark is not:

• A government seal.
• Copyright registration.
• A statutory certificate.
• A licence to use the work.
• A finding of legal ownership.
• A guarantee that every claimant statement is true.
• A prediction of a court outcome.
• Evidence that WIPO, C2PA, CAI, IPTC or another organisation endorses EviWrite.

The E-mark verifies the EviWrite record - not every legal conclusion that might later be argued from it.

5. Drafts, versions and development history

A finished file is only one point in the history of a work.

EviWrite can create separate records for supported materials such as:

• Early drafts.
• Revised drafts.
• Source files.
• Manuscripts.
• Project files.
• Design iterations.
• Audio stems.
• Video cuts.
• Working exports.
• Research materials.
• Prompts and AI workflow information.
• Components or ingredients.
• Metadata states.
• Content Credential states.
• Final released versions.

Each recorded version may have its own fingerprint, EviWrite Official Timestamp, associated information and declared relationship to other versions.

When properly maintained, these records can create a more informative chronology than a single final deposit.

That chronology may help show:

• The order in which versions were recorded.
• Continuity of development.
• When a particular element appeared in the recorded sequence.
• Which source materials were associated with a version.
• How a final work relates to earlier recorded stages.

The chronology does not automatically determine authorship, ownership or originality.

It provides structured evidence against which those questions may be assessed.

---

Content provenance and metadata

Scope is determined by the current capability register

Modern digital assets may contain several forms of technical provenance and metadata.

EviWrite distinguishes these layers rather than combining them into a general claim of "authenticity."

Potentially relevant layers include:

• CAI-style tools and workflows.
• C2PA provenance manifests.
• Content Credentials.
• Durable Content Credentials.
• Cryptographic signatures and content bindings.
• Certificate and trust-list information.
• Electronic timestamps.
• IPTC media metadata.
• Technical file metadata.
• Rights and licensing metadata.
• Digital-source information.
• AI-system and prompt metadata.
• Ingredient and transformation history.

Discussion of a technology on this page does not mean that every feature is currently operational.

Each capability should be assigned one of the following statuses in EviWrite's current Technical Scope and Assurance Register where published:

• Operational
• Limited availability
• In development
• Not supported

Only capabilities identified as Operational for the relevant record type are represented as completed parts of that evidence process.

The register may identify:

• Supported file formats.
• Supported standard versions.
• Validator or library versions.
• Trust-list source and snapshot date.
• Metadata fields preserved.
• Validation limitations.
• Whether results appear in the record.
• Whether processing is production, limited or experimental.

Roadmap capabilities are not presented as completed evidence features.

---

CAI, C2PA and Content Credentials

Related, but not interchangeable

Content Authenticity Initiative

The Content Authenticity Initiative, or CAI, develops open-source tools and implementation resources that help organisations generate, read, inspect and display Content Credentials.

C2PA

The Coalition for Content Provenance and Authenticity publishes the formal technical specification governing Content Credentials, provenance manifests, assertions, claims, signatures, content bindings, validation and trust mechanisms.

Content Credentials

Content Credentials are the user-facing expression of provenance information created under the C2PA technical framework.

A C2PA manifest may combine:

• Provenance assertions.
• A signed claim.
• Cryptographic content bindings.
• Certificate information.
• Timestamp information.
• Validation information.

Use of CAI tooling does not itself establish formal C2PA conformance.

Successful parsing of a C2PA manifest does not establish that every assertion is true.

Successful cryptographic validation does not establish copyright ownership.

EviWrite records the particular standard, implementation, version, result and trust context actually used.

---

Evidential support for CAI-style workflows

Where the capability is marked Operational for the relevant record type, EviWrite may preserve evidence concerning the Content Credential produced through a CAI-based or compatible workflow.

That evidence may include:

• Whether a C2PA manifest was present.
• Whether it was embedded, remote or stored separately.
• The active manifest identifier.
• Claim-generator name and version.
• Declared C2PA specification version.
• Cryptographic digest of the observed manifest.
• Available signer and certificate-chain information.
• Trust-list context used during validation.
• Creation, action, ingredient and transformation assertions.
• Hard-binding and soft-binding information.
• Timestamp information.
• Validation success, warning, informational and failure codes.
• Unavailable referenced information.
• Evidence that a credential appeared detached or absent.

EviWrite records the actual implementation and result rather than using "CAI-compatible" as a general assurance label.

---

Capture and preservation of C2PA manifests

A C2PA manifest may contain assertions concerning:

• Asset origin.
• Software or hardware involved.
• Edits and transformations.
• Ingredients or source assets.
• Creation processes.
• AI-related actions.
• Signer information.
• Content bindings.
• Timestamps.
• Other provenance events.

Where operationally supported, EviWrite may preserve:

• The manifest state observed.
• The active manifest.
• Referenced ingredient manifests.
• The relationship between the manifest and the recorded file fingerprint.
• Signer certificate and trust-chain results.
• Timestamp and revocation information.
• Validation output.
• Mismatches, inaccessible resources or unsupported features.
• The validation configuration used.

The evidence record preserves the stated result and context rather than reducing a complex validation to an unexplained green tick.

---

Content Credentials at observation

Where Content Credential processing is Operational for the relevant record type, EviWrite may record whether a credential was:

• Present.
• Accessible.
• Structurally well formed.
• Cryptographically valid.
• Bound to the relevant asset.
• Signed using a credential connected to the selected trust framework.
• Accompanied by warnings.
• Incomplete.
• Invalid.
• Detached.
• Unavailable during validation.

A valid Content Credential may provide meaningful information about the recorded origin or history of an asset and whether signed provenance information has changed.

It does not automatically establish that every provenance assertion is factually correct.

C2PA distinguishes technical provenance and validation from judgments about whether content or provenance assertions are truthful, complete or accurate.

EviWrite's role is therefore to preserve:

• What credential was observed.
• What it stated.
• What validated.
• What did not validate.
• Which trust context was used.
• When the observation occurred.
• Which file fingerprint accompanied it.

EviWrite does not convert the presence of a Content Credential into a finding of authorship, ownership or truth.

---

C2PA trust and conformance

EviWrite distinguishes between:

• Using C2PA terminology.
• Reading a C2PA manifest.
• Successfully validating a manifest.
• Using CAI open-source tools.
• Supporting a particular C2PA specification version.
• Evaluating a signer against a selected trust list.
• Formal listing as a C2PA conforming product.

These are materially different claims.

EviWrite does not describe itself or any component as C2PA conforming unless the relevant product has completed the applicable C2PA Conformance Program and is entitled to make that claim.

Where C2PA validation is operationally supported, the record or capability register may identify:

• Validator and version.
• C2PA specification version.
• Trust-list version or source.
• Timestamp trust context.
• Online or offline validation conditions.
• Revocation-check status.
• Informational, warning and failure codes.
• Date of validation.

Trust lists and certificate states can change. EviWrite therefore distinguishes an original observation from a later revalidation.

---

Preservation of IPTC media metadata

The IPTC Photo Metadata Standard provides widely used structures for administrative, descriptive, technical, copyright and rights-related information associated with images.

Where IPTC processing is Operational for the relevant file and record type, EviWrite may preserve fields concerning:

• Creator and contributor names.
• Copyright notices.
• Rights and licensing information.
• Credit lines.
• Source or supplier.
• Title.
• Description and caption.
• Creation date.
• Creation location.
• Digital source type.
• Image identifiers.
• Job, event or registry identifiers.
• Licensor information.
• Web statements of rights.
• AI system used.
• AI-system version.
• AI prompt information.
• AI prompt-writer information.
• Applicable IPTC namespace and standard version.

Metadata is not automatically verified fact

An IPTC creator field may identify a claimed creator. A copyright field may state a rights claim. A date field may state when an asset was created.

The presence of those values is evidence that the metadata contained those assertions when observed.

It does not, without additional verification, establish that the assertions are legally or factually correct.

EviWrite distinguishes between:

• Metadata observed in the file.
• Information declared by the claimant.
• Metadata protected through a cryptographic provenance mechanism.
• Information verified through a separately defined process.
• Information generated by EviWrite's systems.

Recording a statement is not the same as adopting it.

---

Read-only evidence observation

Where provenance or metadata inspection is Operational, the EviWrite process is intended to preserve the original file state rather than silently modify the file merely to inspect it.

The original file fingerprint is recorded before any separate enrichment or transformation.

This matters because adding or changing metadata can alter an asset and may affect an existing cryptographic content binding.

EviWrite distinguishes between:

• Observing existing metadata.
• Extracting evidence from the file.
• Creating a separate evidence record.
• Modifying the asset.
• Generating a new signed provenance event.

Those operations are not treated as equivalent.

Where applicable, EviWrite:

• Records the original fingerprint first.
• Avoids changing the file during observation.
• Records the provenance and metadata state found.
• Reports validation inconsistencies.
• Does not silently repair credentials or metadata.
• Treats a modified output as a separate file and evidence event.

---

Evidence classifications

Every material statement should disclose its source

EviWrite records classify material information so that a relying party can distinguish recorded evidence from unsupported inference.

Claimant-declared

Information supplied by the claimant and not independently verified merely because it has been recorded.

Observed by EviWrite

Information detected or extracted during the controlled evidence process.

Cryptographically validated

Information whose signature, binding or integrity relationship passed the stated technical-validation procedure.

Externally sourced

Evidence obtained from an identified third-party provider, service, network, certificate authority, trust list or timestamp source.

EviWrite system-generated

Information created by EviWrite's controlled systems, including record identifiers, processing chronology, status and verification results.

Independently verified

Information subjected to a separately defined verification procedure beyond its presence in a file, manifest or claimant submission.

Not determined

Questions the record does not resolve, including legal ownership, authorship, originality, infringement or factual truth where no relevant determination has been made.

This classification prevents:

• A claimant assertion from silently becoming an EviWrite assertion.
• Embedded metadata from becoming presumed truth.
• A valid signature from becoming presumed legal ownership.
• A blockchain anchor from becoming a copyright decision.
• A technical-validation result from being presented as a judicial finding.

---

What an EviWrite record may establish

Subject to its displayed scope and status, an EviWrite record may provide evidence that:

• A specified cryptographic fingerprint was submitted.
• The fingerprint was associated with defined information.
• An EviWrite Official Timestamp was applied.
• The record was created under an identified Evidence Standard version.
• Particular information was declared by a claimant.
• Particular metadata or provenance information was observed.
• A particular Content Credential or C2PA manifest was present.
• A stated technical-validation process produced a stated result.
• A signer or timestamp credential had a stated status under the selected validation context.
• A cryptographic representation of the record was externally anchored.
• A later file produced the recorded fingerprint.
• Several drafts or versions were recorded in a stated sequence.
• The E-mark corresponded to a current EviWrite record when checked.
• The record had been corrected, superseded, limited, suspended or revoked.

The strength of any conclusion depends on the evidence actually contained in the individual record.

---

What an EviWrite record does not establish by itself

The existence of an EviWrite record does not automatically prove that:

• The claimant possessed the underlying file unless the record includes an applicable proof-of-possession control.
• The claimant created the work.
• The claimant owns every relevant right.
• The work is original.
• The work does not infringe another person's rights.
• Every claimant statement is true.
• Every metadata field is accurate.
• Every C2PA assertion is factually correct.
• The EviWrite Official Timestamp is the original creation time.
• No earlier version exists elsewhere.
• The claimant was the first person to possess the work.
• Copyright has been registered.
• A government body has approved the claim.
• A court must accept the claimant's interpretation.
• A dispute will be resolved in the claimant's favour.

These limitations do not weaken the record.

They define the weight the record can reasonably bear.

Evidence becomes less credible when it claims more than it can establish.

---

Governance and accountability

Authority must remain reviewable

The controls currently in force are identified in the applicable EviWrite Evidence Standard and supporting governance documents.

Depending on the relevant standard version and operational scope, those documents may address:

• Standard versions and effective dates.
• Evidence classifications.
• Acceptance requirements.
• Record statuses.
• Correction and supersession.
• Suspension and revocation.
• Conflicts of interest.
• Restrictions on commercial override.
• Administrative audit trails.
• Incident handling.
• Retention and deletion.
• Cryptographic-algorithm migration.
• Business continuity.
• Disaster recovery.
• Technical or control assessments.
• Known limitations.

A procedure is not represented as operational merely because it appears as a general principle on this page.

Material changes to an evidence record must be attributable and visible under the applicable procedure.

A completed record is not silently rewritten merely because its original status is inconvenient to EviWrite or the claimant.

Commercial importance does not determine the technical record result.

Payment purchases access to the service. It does not permit alteration of the record outside the governed process.

---

Continuity and long-term verification

The continued availability of an EviWrite webpage is not the same as independent long-term verification.

An individual record should state which continuity mechanisms it includes, such as:

• A publicly inspectable external anchor.
• A downloadable evidence record.
• A machine-readable record representation.
• An EviWrite digital signature.
• Timestamp evidence.
• An anchor receipt.
• A Merkle inclusion proof where applicable.
• The applicable Evidence Standard version.
• Verification instructions.
• Relevant public-key or certificate information.

Where these materials are not included, verification may remain dependent on continued operation of EviWrite's service.

EviWrite does not describe a record as capable of standalone or long-term independent verification unless the materials required for that verification are actually provided.

The current Technical Scope and Assurance Register should identify the continuity mechanisms available for each record type where published.

---

Technical scope and assurance

The technical capabilities applicable to an individual record depend on:

• The applicable Evidence Standard version.
• The record type.
• The file format.
• The technologies present in the asset.
• The validation tools available.
• The selected evidence process.
• The capability status at the time.
• The information displayed in the resulting record.

The use of a standard, tool or technology name does not mean that every feature of that standard is supported.

The Technical Scope and Assurance Register may identify, where applicable:

• Capability status.
• Supported file types.
• Supported cryptographic algorithms.
• Algorithm-deprecation policy.
• EviWrite Official Timestamp method and provider.
• External blockchain network.
• Anchoring method.
• Supported C2PA specification versions.
• Validator and library versions.
• C2PA conformance status.
• Trust-list and timestamp-trust-list support.
• Supported Content Credential formats.
• Supported IPTC metadata versions.
• Metadata fields preserved.
• Provenance-validation limitations.
• Evidence-retention information.
• Backup and recovery assurance.
• Last relevant review or test date.
• Material incidents affecting reliance.
• Public-verification service status.

The individual record and applicable Evidence Standard define what was actually performed.

---

What external references mean

EviWrite cites legal, technical and industry sources to explain recognised principles relevant to its methodology.

These references support concepts including:

• Automatic copyright protection and the continuing need for proof.
• Cryptographic fingerprinting.
• Detection of changed data.
• Electronic timestamping.
• Blockchain anchoring.
• Verification without disclosing the underlying file.
• Content provenance.
• C2PA validation and trust.
• Content Credentials.
• IPTC metadata.
• Operational resilience.
• Independence and objective assessment.
• Privacy and pseudonymisation limitations.

The cited organisations have not accredited, approved or endorsed EviWrite unless an express statement says otherwise.

A reference may establish that a principle or method is recognised.

It does not establish that EviWrite has implemented that principle correctly.

EviWrite is responsible for substantiating its own implementation through:

• The EviWrite Evidence Standard.
• Technical disclosures.
• Capability status.
• Public verification.
• Record-level evidence.
• Control documentation.
• Measured service data where published.
• Independent assessments where available.

EviWrite does not borrow another institution's authority.

It identifies the external foundations that inform its methods and accepts responsibility for proving how those methods are implemented.

---

Technical and legal references

UK Government and Intellectual Property Office

Supports the statements that UK copyright generally arises automatically and that there is no public or government copyright register.

Copyright notices - GOV.UK

Copyright - GOV.UK

World Intellectual Property Organization

Supports the use of cryptographic hashes, timestamping, proof-of-existence methods and blockchain records that can be checked without disclosing the confidential document represented by the hash.

WIPO does not sponsor or endorse EviWrite.

WIPO Guide to Trade Secrets and Innovation - Trade Secrets and Digital Objects

WIPO PROOF - Discontinued Service

National Institute of Standards and Technology

Supports the use of secure cryptographic digests to detect changed data and the description of blockchain as tamper-evident and tamper-resistant.

NIST FIPS 180-4 - Secure Hash Standard

NIST - Blockchain

NIST IR 8202 - Blockchain Technology Overview

European Commission

Supports the principle that an electronic timestamp links electronic data to a particular time and can provide evidence that the data existed then.

Electronic Identification and Trust Services - European Commission

eSignature and Trust Services FAQ - European Commission

Coalition for Content Provenance and Authenticity

Supports the structure of C2PA manifests, assertions, signed claims, hard and soft bindings, validation, trust lists, timestamps and formal conformance.

It also supports the distinction between technical provenance and factual truth.

C2PA Specifications

C2PA Conformance Program

C2PA Conformance Explorer

Content Authenticity Initiative

Supports the relationship between CAI open-source tools, Content Credentials and the C2PA technical standard.

Content Authenticity Initiative - How It Works

CAI Open-Source Documentation

International Press Telecommunications Council

Supports the preservation and interpretation of descriptive, administrative, rights-related, digital-source and AI-related media metadata.

IPTC Photo Metadata Standard

IPTC Photo Metadata Standard 2025.1

Financial Conduct Authority

Provides an established reference framework for operational resilience, disruption testing, recovery capability and planning for important services.

EviWrite does not claim FCA authorisation or regulation through its use of related resilience principles.

Financial Conduct Authority - Operational Resilience

Financial Reporting Council

Provides established principles concerning integrity, objectivity and independence in audit and public-interest assurance.

EviWrite does not claim to perform a statutory audit or to be governed as an audit firm.

Financial Reporting Council - Ethical Standard for Auditors

Information Commissioner's Office

Supports the distinction between hashing, pseudonymisation and anonymisation, including the possibility that hashed values may be compared with known or guessed inputs.

Information Commissioner's Office - Pseudonymisation

---

The record before release

Evidence is generally easier to preserve before a dispute begins.

A valuable time to begin the record is while the work remains under your control:

• Before the pitch.
• Before the submission.
• Before the collaboration.
• Before the upload.
• Before the publication.
• Before the release.

Create an additional record held and timestamped separately from your own files and internal systems.

For supported hash-only records, the original file need not be uploaded.

Add drafts and versions as the work develops.

Preserve relevant Content Credentials, C2PA provenance and IPTC metadata where those capabilities are shown as Operational for the selected record type.

Give a future reviewer more than a date or screenshot held only on the claimant's own system.

Copyright may be automatic. The record is not.

Before it leaves your hands, make the record.

Make the record

Hash-only for supported records.
Externally anchored where stated.
Publicly checkable through EviWrite.
Governed by the applicable EviWrite Evidence Standard.