Service Status and Availability

Effective date: 29 March 2026
Last updated: 29 March 2026

This page explains how EviWrite ("EviWrite", "we", "us", or "our") approaches service availability, maintenance, interruption handling, and status communication across its public website, verification surfaces, and authorised operational services.

This page is intended to clarify posture and expectations. It is not a public guarantee of uninterrupted service, a binding service-level commitment, or a substitute for any private contractual service terms that may apply to authorised institutions, licensees, or approved partners.

1. General service position

EviWrite operates in a trust-sensitive evidential context. That means service continuity matters, but so does service restraint.

A serious system is not judged only by whether it is always reachable. It is also judged by whether it fails safely, recovers cleanly, preserves integrity, and avoids pretending that superficial availability is the same thing as trustworthy operation.

2. Public services and restricted services

EviWrite may operate more than one category of service surface, including for example:

• public informational pages;
• public verification and interpretation pages;
• public-ledger and related public trust surfaces;
• restricted-access services used through authorised institutions, licensees, or private arrangements;
• internal or controlled operational systems not intended for public use.

Availability, protection, and visibility may differ across these categories.

3. No guarantee of uninterrupted availability

EviWrite does not guarantee that every page, route, verification surface, or related service will be available at all times or without error.

Availability may be affected by, among other things:

• maintenance;
• deployments or upgrades;
• infrastructure events;
• provider or network failures;
• security measures;
• abuse-prevention controls;
• denial-of-service conditions;
• legal or operational restrictions;
• dependency outages.

The correct standard is not fantasy uptime language. It is controlled operation under real conditions.

4. Maintenance and controlled changes

EviWrite may perform scheduled or unscheduled maintenance, upgrades, migrations, patches, or operational changes at any time where reasonably necessary.

That may affect:

• access speed;
• page availability;
• verification response times;
• public route behaviour;
• internal service continuity;
• specific partner or workflow integrations.

Where practical, material planned changes may be reflected through relevant status communication channels. Not every internal or low-level change will be announced publicly.

5. Security-first interruptions

EviWrite may restrict, degrade, rate-limit, challenge, isolate, or withdraw certain public or operational functions where reasonably necessary to:

• protect service integrity;
• contain suspected abuse;
• defend against attack;
• preserve evidential trust;
• avoid propagation of a faulty or misleading state;
• protect infrastructure, records, or authorised workflows.

A partial shutdown in defence of integrity may be preferable to a false appearance of normality.

6. Verification and public trust surfaces

Verification and related public trust surfaces may be subject to stronger controls than ordinary static pages because they are more sensitive to:

• scraping;
• probing;
• distortion;
• automation abuse;
• misleading replay;
• hostile or high-volume access patterns.

As a result, a user may sometimes encounter throttling, delay, or temporary restriction on certain routes without that meaning the service has broadly failed.

7. Public status communication

EviWrite may publish, update, or withhold public status information at its discretion.

Status communication may include, where appropriate:

• notices of known incidents;
• degraded-service notices;
• maintenance notices;
• integrity-related notices;
• recovery-progress statements;
• acknowledgments of resolved issues.

EviWrite is not obliged to disclose internal incident detail, attack detail, security-sensitive information, or dependency-specific confidential information simply because service behaviour has changed.

8. Timing and incident communication

Not every issue is suitable for immediate public explanation.

In some situations, EviWrite may delay or limit public comment where doing so is reasonably necessary to:

• protect security;
• avoid misleading partial explanations;
• prevent exploit amplification;
• preserve legal position;
• allow technical verification before public statement;
• avoid false reassurance.

Accuracy matters more than speed theatre.

9. Dependency and infrastructure limits

EviWrite may rely on third-party infrastructure and supporting providers for hosting, delivery, routing, security, storage, communications, or related technical functions.

Where those providers experience issues, EviWrite service behaviour may be affected even where EviWrite itself has not failed in isolation.

That does not remove EviWrite’s responsibility for its own posture. It does mean public availability is influenced by components outside a single box.

10. Temporary inconsistency and propagation delay

Some public surfaces may reflect updates, corrections, or state changes at slightly different times depending on caching, propagation, system reconciliation, or controlled release behaviour.

A short-lived difference between two surfaces does not automatically mean an integrity failure. It may reflect ordinary timing differences in distributed systems.

11. No promise of public operational transparency at total depth

EviWrite may choose to publish some status information. It does not commit to publishing a full operational diary, infrastructure map, incident log, or attack chronology.

A service designed for serious evidencing should not confuse public reassurance with uncontrolled operational disclosure.

12. Restricted and partner-facing service expectations

Authorised institutions, licensees, and approved third parties may in some cases receive more specific service communication, workflow notices, or contractual expectations than those shown on public pages.

Nothing on this page should be read as replacing any specific written service terms applicable to those relationships.

13. Public-ledger and anchoring expectations

Where public-ledger or anchoring-related surfaces are available, those surfaces may be subject to:

• publication delay;
• batching behaviour;
• controlled update cadence;
• validation steps;
• temporary pause where integrity review is required.

An evidential service should prefer a defensible publication state over a hurried but unreliable one.

14. User responsibilities

Users should not treat:

• a temporary delay;
• a challenge page;
• a timeout;
• an unavailable route;
• a cached older view;
• a restricted verification response

as proof of non-existence, invalidity, or system abandonment.

Service conditions and evidential meaning are separate questions.

15. Incident response posture

Where a material issue occurs, EviWrite may take steps such as:

• investigate and confirm the issue;
• isolate affected systems or routes;
• preserve logs and operational evidence;
• apply mitigations;
• restore service in stages;
• validate integrity before full resumption;
• communicate externally where appropriate.

The sequence is deliberate. Restoration without validation is not a serious response.

16. No waiver through availability

The fact that a route is reachable does not mean every underlying assumption a user makes about it is correct. Conversely, the fact that a route is temporarily unavailable does not erase records, rights, or status by itself.

Availability is operational. Meaning is defined separately.

17. Changes to this page

EviWrite may update this page from time to time to reflect changes in public surfaces, operational model, service structure, or communication posture.

18. Contact

For status-related enquiries, contact:

contact@eviwrite.com

Final point

A serious evidential service should aim not merely to stay up, but to stay reliable when being up matters most.