Trust

Security & Trust

Last updated: September 9, 2026

This page describes the architectural controls TRACE Management System's project-record and evidence-assistance systems are actually built with today, and is deliberately plain about what is not yet true — including formal third-party certification. If you are evaluating TRACE Management System for a public-agency or enterprise procurement and need something this page doesn't answer, contact us directly.

Where we are today: ZECO CM LLC, the operator of TRACE Management System, is an early-stage company. We have not completed a SOC 2 audit, FedRAMP authorization, or an independent penetration test. The controls below are real and enforced in the application today, but they have not yet been verified by an outside auditor. Treat any claim on this page as "built this way," not "certified this way," until we say otherwise.

Security layers at a glance

1 · Tenant boundariesEvery project-data request stays within the customer and project context authorized for that user.
2 · Role-based accessAuthenticated users receive only the project tools and actions allowed by their effective role.
3 · Encrypted transportBrowser traffic uses HTTPS/TLS while project files remain inside controlled application storage.
4 · Accountable historyGoverned records preserve attributable changes, superseded states, citations and supported integrity information.
5 · Daily protected backupA scheduled encrypted archive covers the database, application, configuration and evidence storage.
6 · Recovery and exportAdministrators can run an additional on-demand backup, and portable project exports reduce platform lock-in.
Tenant isolation The append-only evidence model Authorization-scoped TRACE Intelligence Access control and authentication Encryption and infrastructure Controlled recovery Backups and recoveryData export and portability Retention and deletion Subprocessors Reporting a security issue

Tenant isolation

Every request that reaches project data is scoped to a tenant. Customer-side users always carry their own tenant context and cannot see another organization's projects, documents, or records. Platform staff accounts carry no tenant context by default; a staff member can only see a specific customer's data by deliberately switching into a browse-tenant context for that customer, and that action is not silent — it changes what the account can see for the duration of the session, not a standing permission.

The append-only evidence model

Governed determinations — certifications, change-order approvals, contract-clock calculations, TRACE citations and refusals — are never silently edited in place. A correction supersedes the prior state and is recorded alongside it, not over it. This is the same property the homepage describes as "the present never rewrites the past," and it applies to the underlying data model, not just the marketing copy.

Authorization-scoped TRACE Intelligence

TRACE only retrieves documents and records the requesting user is already authorized to see under the tenant-isolation rules above — it never infers access from a higher-privileged grant elsewhere in the system. A substantive TRACE answer requires a citation to project evidence; when the evidence is insufficient, contradictory, or unreliable, TRACE is designed to escalate or refuse rather than guess. Content extracted from customer documents (including OCR'd text from scanned drawings) is treated as untrusted data, not as instructions to TRACE — a drawing or PDF cannot direct TRACE to take an action or change its own behavior.

Access control and authentication

Application access is authenticated per user, with role-based permissions that separate ordinary project users from platform administrators. We do not ask users to share credentials, and we do not store payment card data ourselves — payment processing, where applicable, is handled by a third-party processor.

Encryption and infrastructure

Traffic between your browser and TRACE Management System is encrypted in transit (HTTPS/TLS). The production infrastructure is currently a single-region deployment operated by a small engineering team rather than a large multi-region hosting footprint. We are direct about this because it is a real characteristic of an early-stage product, and because it should factor into your own risk assessment — it is not something we ask you to take on faith.

Self-Recovery

Resilient operations with bounded autonomous remediation

TRACE applies bounded, deterministic recovery to defined operational conditions. These controls protect retryable processing and the integrity of the project record; they do not authorize TRACE to reverse a business decision, approval, certification, or other accountable human action.

Duplicate-request protectionEligible mutations use a tenant-, user-, route- and content-bound request identity. Matching retries replay the completed result; conflicting content is refused.
Stale-work handlingTime-bounded leases, claim tokens and current-state snapshots keep expired or superseded workers from changing newer records.
Bounded retry and quarantine sweepsScheduled recovery processes inspect eligible quarantined or interrupted work, apply attempt and cooldown limits, and route only defined cases back through controlled processing.
Integrity and recovery evidenceRecovery state, outcomes, hashes and attributable events provide a reviewable trail without silently rewriting governed history.

When TRACE cannot establish that a write is safe, it refuses the write and records the condition for authorized review.

Backups and recovery

TRACE runs a scheduled encrypted backup every day. The protected archive includes the PostgreSQL database, application and configuration, private evidence storage, and public uploads.

Current recovery boundary: TRACE currently operates in a single-region environment. The daily archive is verified, while a full production restore drill and multi-region recovery are not represented as completed controls. Public-agency or enterprise requirements for retention, off-site copies, recovery time, or recovery-point commitments should be written into the implementation scope.

Data export and portability

TRACE Management System is built so that leaving the platform does not mean losing your evidentiary record: the export path is designed to produce your project's record, provenance, hashes, and verification information in a portable package that can be checked without continued access to the TRACE application. We do not consider your project history something we should be able to hold hostage.

Retention and deletion

Project records are retained for the duration of your organization's agreement with ZecoCM and for any additional period required by the public-records or contract-retention rules applicable to your project. See our Privacy Policy for how this applies to personal information specifically.

Subprocessors

ZecoCM relies on a small number of infrastructure and AI-model subprocessors to operate the Service (for example, cloud hosting and the AI model provider behind TRACE). A current list is available on request at info@tracems.com.

Reporting a security issue

If you believe you've found a security vulnerability in TRACE Management System, please report it to support@tracems.com before disclosing it publicly. We will acknowledge reports and work with you in good faith to understand and address the issue.

This page is a plain description of current architecture, not a security certification, a warranty, or a substitute for your own organization's security or procurement review. Nothing here overrides the terms of a signed agreement between your organization and ZECO CM LLC