Security standards.

Every tenant record carries an organisation identifier and is read under organisation-scoped rules. Covered by an automated acceptance test: the signed-in user's query returns only their own organisation's records, and a record belonging to another organisation is withheld.

Shared server-side guards resolve the caller's organisation and role from the session and authorise the operation before it executes; the request body is never trusted for identity or tenant. Covered by an automated acceptance test: an unauthorised role is refused with 403.

Implementation status, approval verification and briefing-request queues are gated to the platform owner and do not render for client administrators. Established by reading the implementation.

Two-organisation cross-tenant testing is outstanding, and platform-administrator support access is not yet separated from client administration. Isolation therefore rests on the rules and guards above rather than on a completed negative-test programme.

Sessions, token issuance, password resets and email verification are handled by the hosting platform. No credential is issued, stored or validated by application code.

Accounts exist by invitation for named individuals. Organisation membership is recorded server-side and resolved on each protected request. Established by reading the implementation.

Registration and access are restricted to the company's corporate domain through platform authentication configuration — a platform setting rather than application logic.

Not enabled on this deployment. The platform supports enterprise SSO configuration; it is not currently switched on, and multi-factor enforcement has not been configured or tested.

Uploaded evidence is written to private storage and reached only through a time-limited signed link generated for an authorised caller; the file is not reachable by its reference alone. Covered by an automated acceptance test.

Each evidence item records its classification — public, internal, confidential or restricted — together with its provenance, version and validity window. Established by reading the implementation.

All application traffic is served over TLS by the hosting platform. ARETE has not independently tested the platform's TLS configuration.

Storage encryption is provided by the hosting platform. ARETE has not independently verified the platform's at-rest configuration or its key management.

No documented data-residency position and no sub-processor register have been published. Both must be completed before they can be relied upon in a client's own assessment.

Accepting evidence requires a reviewer who is a different person from the submitter. The same independence gate governs analysis review and obligation approval. Covered by an automated acceptance test — a self-decision is refused.

An upload lands as submitted, never as accepted. No action available to a submitter in the interface can move evidence to accepted; only the review path can.

A decision in flight holds a transient election token that is cleared when the decision lands, so two reviewers cannot record conflicting outcomes against the same item. Established by reading the implementation.

Captured source text is hashed deterministically and preserved as an immutable version, with duplicate detection and a verified-before-analysis gate. Covered by an automated acceptance test.

Evidence carries its validity window and can hold an expired state, but expiry is not scheduled: no automatic transition or reminder runs when a validity date passes.

Material operations write an audit event from server-side logic naming the actor, the object and the context of the change. Covered by an automated acceptance test: one lifecycle records one event per transition, each naming the same object identifier.

Report generation records the scope applied, the identifiers of every record included and any limitations raised, and writes an audit event before the export stands. Covered by an automated acceptance test.

Audit events are not reconciled against the objects they name, and the trail has no retention policy. Events have been observed naming records that no longer exist, so a populated trail must not be read as proof that its objects still exist.

No integrity chain is computed over the trail. It is append-only by application convention rather than cryptographically sealed: an application administrator can delete events, and the export caps at the 200 most recent.

Every analysis run is persisted as its own record with the inputs assembled, the model and prompt version, the retrieval method and timestamps. Covered by an automated acceptance test.

No analysis output affects a downstream record until a human reviewer has approved it, and approval requires a reviewer other than the person who ran it. Covered by an automated acceptance test.

When the AI provider is unavailable the run persists a labelled fixture recording that fact, and a fixture run can never be approved. Covered by an automated acceptance test.

Each finding carries its assumptions, uncertainty notes, warnings and a self-reported confidence value that is never treated as authority. Established by reading the implementation.

AI-execution functions apply a per-organisation hourly request limit, so a single tenant cannot consume shared capacity unchecked. Established by reading the implementation.

Organisation configuration is written server-side: each section is validated against a fixed shape, changes are limited to the organisation administrator, audited, and readiness is recomputed from what is actually stored. Established by reading the implementation.

Configuration changes appear in the audit trail but are not versioned, so a previous configuration state cannot be restored from the platform.

Each external integration records its counterpart, authorised data scope, classification and a state that includes quarantined and revoked, so an exchange can be stopped without deleting its history. Established by reading the implementation.

Inbound handlers require a shared secret presented with the request and deduplicate runs idempotently, so a repeated delivery does not create a second record. Established by reading the implementation.

Credentials and API keys are held in the hosting platform's secret store and read server-side at execution time. No secret is embedded in client code.

Deadline reminders, evidence expiry and the governance monitoring sweep are implemented as scheduled background tasks, each recording what it covered so the same event is not notified twice. Whether the daily schedule invoking them is configured on the deployed environment must be confirmed: until it is, they run only when an administrator invokes them by hand. Established by reading the implementation.

Security concerns, vulnerability reports and institutional due-diligence requests are directed to the security contact address, admin@aretestrategyai.org, and acknowledged by the company.

No service-level agreement and no uptime report are offered at this stage. Service continuity depends on the hosting platform's own availability.

No continuity registry, recovery-time objective or tested recovery procedure exists for the platform. Institutional continuity is registered as a planned capability, not an existing control.