Service status

Specify is currently pre-production

Pre-production, no production service level applies

The application is under active development and is not yet operating under a public production service commitment. This page reports the health of the publicly available website and demonstration services separately from future production services.

States on this page are declared rather than continuously measured. The site is statically hosted with no server at request time, so this page cannot itself detect an outage. An independent monitoring source is a production requirement, and until it exists this page is maintained by hand.

Last reviewed The date below is the last time these states were reviewed, not a live timestamp.

Components

  • Public website

    Operational

    Fully prerendered static site with no server dependency. Includes the complimentary Enquiry Audit interface and every public page.

  • Enquiry Audit processing

    Pre-production

    Analysis of a submitted enquiry. Depends on the commerce API and an external model provider, and runs under development-hours support.

  • Form submissions

    Pre-production

    Audit, Sprint, consulting, talent, investor and founding-partner submissions. Depends on the content service.

  • Merchant application

    Pre-production

    The authenticated merchant interface. Not generally available and not operating under an availability commitment.

  • Commerce API

    Pre-production

    Authentication, opportunities, decisions and merchant data. Deployed to a development environment only.

  • Content service

    Pre-production

    Merchant content, the AI assistant and its policy engine. Deployed to a development environment only.

  • AI-assisted interpretation

    Pre-production

    Optional throughout. When the provider is unavailable the assistant reports itself unavailable and no other behaviour changes.

Incidents

No incidents have been recorded. This section will hold the full history once production begins, and resolved incidents are not removed from it afterwards.

How incidents will be reported:

  • An entry is opened when customers are affected, with the observable impact stated rather than a guess at the cause.
  • Updates carry a time and say when the next update is expected.
  • Statuses move through investigating, identified, monitoring and resolved.
  • Resolution is confirmed after checking that data is intact, queues are processing and no duplicate actions were sent, not when the service starts responding.
  • A material incident gets a proportionate written summary afterwards, without security-sensitive detail.
  • Resolved incidents stay published. A record is not removed because it is unflattering.

Planned maintenance

No maintenance is scheduled.

Planned maintenance will be posted in advance with the expected window, the affected components and the expected impact. Emergency work is recorded as an incident and is never reclassified as planned maintenance afterwards.

Availability history

No availability figure is published, and none will be until production begins and an independent monitor is measuring it. A percentage derived from development deployments would describe something no customer depends on.

When measurement begins, the published figure will state:

  • Which workflow is measured rather than which process is alive.
  • Which responses count as successful.
  • The measurement frequency, regions and window.
  • How partial failures and scheduled maintenance are treated, including whether maintenance is excluded.

History will not be reset or rewritten after launch, and a change to how availability is measured will be recorded here rather than applied quietly.

Reporting a problem

If something is not working and this page does not reflect it, that is a gap in our monitoring rather than an error on your part. Technical and security contact routes are on the technical page.

Read the technical page Report a security issue