Transparency
The full accounting. What we publish, what we don't yet, and what we owe you either way.
The AI industry has a transparency problem. Companies publish capability claims without publishing failure rates. They announce certifications before audits complete. They post incident pages that go dark before root causes are documented. They write privacy policies for legal cover, not for comprehension.
This page is our answer to that. What we currently publish, what we've committed to and haven't shipped yet, what we're still working out, and what we got wrong. We update it when things change. Past versions are archived. We don't edit our commitments quietly and we don't remove entries that didn't go as planned.
The standard
What transparency means to us
We mean: if something goes wrong with the platform, customers hear it from us first — before they find it themselves. If a certification is in progress, we say "in progress," not "certified." If Amara makes a class of errors we've identified, we document it. If a government asks us for customer data, we publish the aggregate request count in our annual report and describe how we responded.
We also mean being transparent about what we don't know. Amara is a frontier model. Frontier models have failure modes that aren't fully understood at the time of deployment. We publish what we've found in red-teaming and evaluation. We update our model cards when we find new things. We don't wait until a failure is widely observed before acknowledging it.
Transparency isn't a page you ship once. It's a practice. This page is the artifact of that practice — updated continuously, not polished annually.
Published now
What we publish today
Everything below is live today. If something listed here is incomplete or outdated, that's a failure on our part — email trust@syntic.ai and we'll fix it.
Trust Center
Our security posture, active and in-progress certifications, data handling policies, full subprocessor list, data residency options, retention schedules, and the documentation procurement and legal teams actually ask for. Updated when things change, not on a quarterly schedule. If something on your diligence checklist isn't there, email trust@syntic.ai — we'll tell you where it stands and when it will be published.
Responsible disclosure program
Security researchers can report vulnerabilities at security.syntic.ai. We acknowledge every report within 24 hours. Verified findings get a substantive response within 48. We don't close a report without telling the researcher what we found and what we did about it. Significant resolved vulnerabilities are published as advisories — including honest severity ratings and impact scope, not minimised versions. Significant findings are compensated on a case-by-case basis today. A formal structured bug bounty program is on the 2027 roadmap.
Service status
Real-time platform health and full incident history at status.syntic.ai. We post customer-facing incidents as they're identified — not after resolution. Every incident page stays open until root cause is documented, not just the fix. We don't archive incident history. Every outage we've ever had is on that page, with the honest account of what happened.
Model cards and known limitations
We publish model cards for each Amara tier covering intended use, known failure modes identified in evaluation and red-teaming, performance across demographic groups, and behaviours we're actively working to improve. Model cards are updated with each major model release and when we identify new material limitations between releases. Published at syntic.ai/research/model-cards.
Research publications
Syntic Research publishes openly on alignment, evaluation, multi-agent coordination, autonomy thresholds, voice, and safety. Papers are published under individual researcher bylines, go through internal peer review and external academic review where appropriate, and are not filtered for competitive sensitivity unless they would compromise active customer security. Full publication archive at syntic.ai/research.
Acceptable use enforcement
Our Acceptable Use Policy is published at syntic.ai/legal/aup. Enforcement actions — account suspensions, content removals, deployment terminations — are logged internally and reported in aggregate in our Annual Transparency Report. We don't publish individual enforcement actions except where legally required or where the public interest clearly outweighs privacy considerations.
Not yet published
What we're working toward
These are commitments with dates attached. If a date slips, we update this entry before the deadline passes and explain why. We don't silently push dates and hope nobody notices.
Independent audit reports
SOC 2 Type II is in progress with a Big Four auditor. Target completion Q4 2026. We will update this entry to “certified” the day the certificate is issued — not before. ISO 27001 ISMS implementation is underway, target Q1 2027. When each report issues, a public summary goes on this page and the full report becomes available under NDA through the Trust Center. If either date moves, this entry gets updated with the new date and the reason before the original deadline passes.
Annual Transparency Report
Starting with our first full operating year, we will publish an annual Transparency Report covering: platform uptime by product and region; government and law enforcement data requests received, contested, and complied with; content moderation and acceptable use enforcement actions in aggregate; safety incidents and how we handled them; Amara evaluation results including areas where the model underperformed; and an honest scorecard against the commitments on this page — including the ones we missed. First report Q1 2027. It will include what didn't go well.
Incident postmortem archive
For every material customer-impacting incident, we publish a redacted post-incident review within 30 days of resolution. Each review covers: timeline of detection and response; customer impact scope; root cause, including contributing factors we could have caught earlier; what we shipped to prevent recurrence; and how long each stage of response took. We don't decide unilaterally what counts as material — if a reasonable customer would have wanted to know, it qualifies. The archive is permanent. We don't remove entries. Target launch: our next material incident after this page publishes.
The floor
What we won't do
We won't announce a certification before it's issued. We won't post a status update that says "investigating" and never follow up. We won't publish a transparency report that only covers the things that went well. We won't update this page to remove a commitment we didn't keep — we'll add an entry explaining what happened instead. We won't describe a known model limitation as a "known edge case" to minimise how it reads. And we won't close an incident until the customer impact is fully understood, even if the immediate cause is fixed.
These aren't aspirations. They're the floor. If we fall below it, the right response is to document the failure here, explain it, and fix it — not to edit the page.
Say what's true, say it before you're asked, and update it when it changes.
Everything on this page is written and maintained by the teams responsible for the systems it describes. The documents we publish here are the same ones we give to customers' procurement, security, and legal teams — not a sanitised public version and a real internal one. When this page changes, the change is dated and noted. Past versions are archived at syntic.ai/transparency/archive. The standard is simple: say what's true, say it before you're asked, and update it when it changes. We'll hold ourselves to it.