Technical questions
Technical confidence should come from evidence, not adjectives
Specify is pre-production. This page describes the system we are building toward and how it is designed, so a technical reader can judge whether the engineering is serious before anything is at stake.
The design principles are isolation, durability, controlled change, observable operation and an explicit boundary between what software may interpret and what a business has actually approved. That last one is the part most commerce systems get wrong, and it is the part Specify is built around.
Current stage: Pre-production
The platform is under active development and validation, and is not yet operating under a public production availability commitment. Controls described below as production requirements are design commitments rather than completed work, and we will not describe a proposed safeguard as though it has already been tested.
How it is designed
Five principles the architecture is built on
These are decisions taken early, because each becomes expensive to retrofit. They are what an architect would want to interrogate first.
- Failure is contained, not prevented
- The system is designed to fail in bounded, observable and recoverable ways rather than to claim it will not fail. Optional capability degrades without taking core commercial records with it, and long-running or failure-prone work is isolated from the request path. The public site is fully prerendered with no server at request time, so it stays available independently of everything behind it.
- Authority is explicit and separate from interpretation
- Interpretive services have no standing authority to change commercial records or commit a merchant. What may be offered comes from approved capability, constraints and pricing rules, enforced deterministically. This is architectural rather than procedural: the boundary holds regardless of what any prompt or model does.
- Tenancy is enforced at the data layer
- Authorisation resolves to a query constraint rather than a check a caller could influence, so a request is scoped to the merchant it belongs to before data is read rather than filtered afterwards. Isolation is covered by tests at both unit and integration level.
- State is durable and schema change is deliberate
- Authoritative commercial data lives in managed PostgreSQL with schema changes applied through reviewed, version-controlled migrations rather than automatic synchronisation, and applied ahead of the code that depends on them.
- Operations are idempotent
- Retries and redelivery are expected conditions rather than exceptions. Repeating an operation must not produce a duplicate commercial record, a duplicate message or a duplicate external action.
Reliable systems are designed to fail in contained, observable and recoverable ways.
Production design
What production looks like, and where we are against it
The design is settled. Some of it is built and in use in development today; the rest are production requirements we hold ourselves to before accepting customer workloads.
- Built and in use
Topology
A statically served public site at the edge, and separately deployed application services behind it: a merchant application, a commerce API, a content service and background workers. Separate deployables with separate failure modes, so an incident in one does not become an outage in all.
- Built and in use
Identity and access
Managed identity with the OIDC authorisation-code flow and PKCE, HttpOnly session cookies, and role-based authorisation applied server-side. Administrative access is separated from ordinary merchant access.
- Built and in use
Tenant isolation
Merchant scoping is applied as a data-layer constraint rather than an application filter, and tenant identity is never taken from a value the caller supplies. Cross-tenant access is tested rather than assumed.
- Built and in use
Change and delivery
Every change is reviewed, built once and tested automatically before it reaches any environment, including integration tests against a real database. Schema migrations run ahead of the code that depends on them.
- Production requirement
Production rollout
Approval-gated production deployment with staged rollout, health gates on error rate, latency and critical-workflow completion, and a tested rollback path. Backward-compatible migrations, with destructive cleanup separated from the change that introduces it.
- Production requirement
Durability and recovery
Automated encrypted backups with defined retention and deletion protection, point-in-time recovery, and replication appropriate to the failure classes it is meant to address. Recovery objectives are set once a restoration has actually been performed and timed, not before.
- Production requirement
Observability
Structured telemetry correlated across services, service-level indicators defined against critical customer journeys rather than process liveness, and synthetic checks that exercise a real workflow. Sensitive values are excluded from logs by construction rather than by redaction after the fact.
- Production requirement
Operational response
Alerts tied to customer-visible failure, each with an owner, an escalation path and a runbook, tested end to end before launch. A defined severity model, a public status channel and a proportionate review after any material incident.
- Production requirement
Security assurance
Automated dependency and secret scanning in the pipeline, a managed secret store with rotation, and independent security testing commissioned at launch and at material risk milestones. Findings are remediated and retested before they are described as resolved.
The subscription helps fund the engineering and operational work required to move from pre-production toward a dependable production service. Paying for something does not make it production ready, and this page does not claim otherwise; what the price buys is the work, not the status.
This is intentionally the level an architect needs to assess the approach. A control-by-control statement of what is implemented, tested and outstanding is available to customers, partners and reviewers under an appropriate agreement, and the form below is the route to it.
AI controls
Interpretation is not authority
AI can help understand a request. It does not independently establish what a merchant has approved.
Most commercial risk in an AI-assisted system comes from a plausible answer being mistaken for an approved one. Specify treats that as an architectural problem rather than a prompting problem, because a boundary enforced by instructions is not a boundary.
- Identity is not a model input
- Which merchant a request belongs to is established from the authenticated session and injected server-side. It is not something a model can assert, and an attempt to supply it is refused rather than ignored.
- Capability is bounded by construction
- The set of actions available to the assistant is fixed in code rather than assembled at runtime, and destructive operations are not among them. No prompt can widen it.
- Changes are classified deterministically
- Every proposed change is evaluated by a policy engine that runs on the resulting mutation rather than on stated intent. Anything unclassified is denied by default, and merchant or platform overrides may only tighten a classification, never loosen one.
- Commercially sensitive data is out of scope
- Pricing inputs, supplier values and internal-only fields are excluded from what the model can read at all, rather than filtered from what it produces.
- Untrusted content is treated as untrusted
- Merchant and customer content is handled as data rather than instruction. Injection can at worst produce a proposed action, which the policy engine then evaluates on its merits.
- Unavailability degrades safely
- When the model provider is slow, failing or unconfigured, the assistant reports itself unavailable and the request is preserved. Nothing invents an answer to cover a failure.
The system prompt is not treated as a security control, because it is not one. Every boundary above is enforced in deterministic code, which is the only reason it can be described here as a control at all.
Technical questions
The questions reviewers ask
Answered directly, including where the answer is no.
Is Specify in production?
No. Specify is pre-production and is undergoing product, infrastructure, security and operational validation. Anything described on this page as a production requirement is a design commitment rather than completed work.
Where is Specify hosted?
On Microsoft Azure, with the public site served statically at the edge and the application services deployed separately behind it. Managed PostgreSQL holds authoritative commercial data and object storage holds media. Regions, resource configuration and network detail are shared under a technical review rather than published.
What availability commitment applies?
None yet, and we will not publish a figure before it is measurable. An indicator is what gets measured, an objective is an internal target and an agreement is a contractual commitment with remedies. Those three are different things and we will not use them interchangeably.
How will data be protected against loss?
Through automated encrypted backups with defined retention and deletion protection, point-in-time recovery, and replication appropriate to the failure classes it addresses. Replication and backups solve different problems and one does not substitute for the other. Recovery objectives will be published once a restoration has been performed and timed rather than estimated.
Can Specify deploy without downtime?
The production objective is to deploy routine compatible changes without interrupting critical workflows, through staged rollout and health gates. Some maintenance, infrastructure changes and emergency operations may still require a controlled interruption, and we would rather say so than promise otherwise.
How is customer data isolated?
Authorisation resolves to a data-layer constraint, so a request is scoped to the merchant it belongs to before data is read rather than filtered afterwards, and tenant identity is never taken from a caller-supplied value. Cross-tenant access is covered by tests at unit and integration level.
Can AI approve a quotation or a commitment?
No. AI may help interpret and structure a request. Commercial authority comes from approved capability, constraints, pricing rules and authorised human or deterministic controls, and the policy engine denies any change it has no classification for.
Is customer data used to train AI models?
No. Submitted customer and company information is not used to train general-purpose models. What is sent to a model provider, and why, is set out in the privacy notice.
Has Specify completed a penetration test or a certification audit?
No. Independent security testing will be commissioned at launch and at material risk milestones. When an assessment happens, we will state its type, scope, date, the reviewer's independence and whether material findings were resolved, rather than referring vaguely to having been audited.
Which standards do you work to?
Our engineering programme uses the NIST Cybersecurity and Secure Software Development Frameworks, the OWASP Application Security Verification Standard and CISA Secure by Design principles as reference points. A framework reference is not the same as certification, independent assurance or completed implementation, and Specify holds no certification today.
Can we request detailed security documentation?
Yes. Architecture summaries, control statements, sub-processor information, data-processing terms and questionnaire responses are available under an appropriate agreement through the form below. We do not publish a detailed control inventory at a public URL, and we will tell you when something does not exist yet rather than sending an adjacent document.
Where can I see current service status?
On the status page, which reports the pre-production state and does not display a production availability figure, because there is no production service to measure yet.
Technical contact
Ask a technical question
Customers, partners and investors can request technical, security or operational information that is not appropriate to publish openly. Architecture summaries, sub-processor lists, data-processing terms and questionnaire responses are all available this way.
Do not include passwords, access tokens, private keys or sensitive production data in this form.
Ask
Ask a technical question
Customers, partners and reviewers can request the technical, security and operational detail that is not appropriate to publish openly.