Trust & Security Overview
aswritten.ai, operated by Synthetic Identity Co. Effective: September 11, 2026 (previous version: June 12, 2026)
aswritten.ai is a platform for installing curated organizational expertise into AI tools, with full provenance. This page summarizes how we handle your data — the architecture, our subprocessors, our commitments, and the controls available to you. The full posture is documented in our Privacy Policy and Terms; for engagement-grade deployments, the Master Services Agreement (MSA) governs.
The Architecture (One Picture)
Your source materials Stay with you, unless you connect an
(transcripts, documents, integration that sends what you
voice memos, internal tickets) designate straight to the Platform
for processing (Commitment 1).
│
│ Your AI tooling refines
│ (under your AI provider's terms)
▼
Refined memory content Submitted to the Platform via MCP
│ with your explicit authorization.
▼
aswritten Platform Extraction pipeline runs under our
│ control (LLM + deterministic
│ SPARQL-validation and LLM-annotation
│ guardrails, with retry). Inference
│ itself is transient.
│
├─→ Customer Perspective Memory file (.md) + extracted SPARQL
│ Data transaction (.sparql) commit
│ (in YOUR repository) atomically to your repository.
│ Digests derived from them, source
│ documents from meeting integrations,
│ and a runs branch of parsed
│ extraction outputs commit here too.
│ This is the canonical source of
│ truth. A synchronous review summary
│ is returned to your AI session;
│ when ingesting onto a branch, a
│ pull request is also opened or
│ updated for diff/merge review.
│
└─→ Operational artifacts Share records (pointers into your
(in OUR DigitalOcean repository, never content),
infrastructure, New York) workflow execution records (14-day
default; these carry the submitted
content while a run is processed;
disabled on single-tenant
deployments), tool-call audit rows
(structured parameters only),
inference usage rows (tokens and
cost, no content), and internal
user/auth/repo-connection records.
NOT the source of truth, and never
leaves SIC-controlled infrastructure.
Deployed Agents Conversations live in your dedicated
(SMS, email, Slack, others) Front inbox. Engagement-grade
enterprise: dedicated Twilio
sub-account under your A2P 10DLC
brand. You observe and intervene in
every conversation in real time.
Five Architectural Commitments
The first three describe what data we receive (and don’t). The last two describe how you stay in control of accuracy on the way in and on the way out.
1. Source materials stay with you, unless you choose an integration that processes them
You never have to send us raw material. Process transcripts, documents, voice memos, recordings, and internal tickets with your own AI tooling, under your existing AI provider agreements, and submit only the memory content you approve: the primary-source excerpts you chose, with your framing. We never connect to the systems where your source materials live.
If you choose one of our automated integrations, such as the Microsoft Teams app or a connected transcription service, the content you designate flows directly from that provider to the Platform for processing, is committed to your repository as a source document alongside what was extracted from it, and is handled under the zero-data-retention inference routing and the retention terms described on this page. Designation is yours: a meeting the app is not added to, or a source you have not connected, is never touched.
2. Your repository is the canonical Perspective; our server-side records are derived
The canonical, source-of-truth representation of your organizational expertise (memories, claims, transactions, digests) is stored as files in a GitHub repository you own and connect. (GitHub Enterprise Server and equivalents are available as customer-controlled storage under a Statement of Work; see Enhanced Deployment Options.) The canonical data resides on your infrastructure at all times; we read and write via API, and we lose access on termination. Alongside the memories and transactions, your repository holds the digests we derive from them, the source documents submitted through a meeting-platform integration, and a runs branch of parsed extraction outputs (no raw model text).
We do not provision or operate repositories on your behalf. A storage option that does not require git, for non-technical users, is on the roadmap and is not available today.
On server-side records. For operations we keep a small set of records in our managed Postgres that reference your repository or describe our own processing: share records (pointer-only: owner, repo, branch/SHA, directory, recipient metadata — no materialized content; resolved on demand by reading your repository at the recorded ref), tool-call audit rows (structured parameters only; free-text content is dropped at write), inference usage rows (tokens, cost, model, a per-call correlation id; no content), and the internal Datomic-backed records that track your account, auth, and repo connections. Separately, workflow execution records on our self-hosted workflow engine carry the submitted content while a run is processed and are pruned at the default 14 days; on a single-tenant deployment this persistence is disabled. Share records depend on continued repository access — if you disconnect the repository, the underlying content becomes inaccessible from SIC’s records. Your repository remains the source of truth. The same holds for quality evaluation of our extraction: it reads your repository through the connection you granted, on demand, and we keep only aggregate metrics and structured logs — never a copy of your content.
All Customer-derived data within SIC’s control stays inside our DigitalOcean infrastructure. The only outbound data flow from our environment is to LLM inference providers, routed through OpenRouter. We do not ship logs, errors, or any other Customer-derived content to third-party observability or monitoring services.
On the credentials we hold. To read and write Customer Perspective Data in your connected repository on your behalf, SIC operates a GitHub App that holds an authenticated private key. This key is currently stored as an environment variable on SIC-controlled DigitalOcean infrastructure (protected by the cloud provider’s transparent block-storage encryption at rest; not application-level encrypted or HSM-protected in the standard offering today). SIC disclaims liability arising from third-party providers’ acts or omissions, including any compromise of a cloud provider’s encryption. Mitigations: you can revoke the installation at any time from your GitHub UI in a single click; we will notify you within 72 hours of any infrastructure incident materially affecting Customer Confidential Information; and on-premises deployment under Enhanced Deployment Options provides full credential isolation from SIC operators (Platform credentials reside in your infrastructure). This is the honest dual of the “data stays in your repo” architectural commitment — your content lives only in your repository, and we hold the authenticated key that authorizes us to operate on it.
Subscribers who require that no submitted content persist on SIC infrastructure at all, customer-accessible operational logs, or further reduction of subprocessor surface can scope a single-tenant managed deployment, on-premises deployment, or customer-controlled storage as Enhanced Deployment Options.
3. Inference is transient and third-party; we never train on your content
We do not store your content to serve inference — model calls carry your content out only for the duration of the request. Inference runs on third-party model providers, routed through OpenRouter. Routing is restricted at the OpenRouter account level to providers operating under zero-data-retention terms, which also excludes any provider that trains on request data; this applies to every account on the Platform. Under an MSA, ZDR-only routing is additionally a contractual commitment. You may also bring your own OpenRouter key, so inference runs under your own OpenRouter account and the restrictions you configure there.
We do not train models on your content. Period.
4. Your repository is the gate (input-side trust)
Memory drafting happens in your AI tooling under your AI provider’s terms; we are downstream of that step. When you authorize a save, our extraction pipeline produces a structured SPARQL transaction representing what the memory means in graph terms. Extraction runs under deterministic and LLM-based guardrails — SPARQL parsing validation, an LLM annotation pass that flags ungrounded claims, and bounded retries — but we apply commercially reasonable care, not a warranty of semantic accuracy. The memory file and the extracted transaction are then committed atomically to your repository, and verification happens through two complementary review surfaces:
- Synchronous review summary. When the save completes, the response to your AI session names what shifted in the graph (zones affected, claims added/changed) and points to the
reviewtool for deeper inspection. Thereviewtool is a deliberate enhancement — a perspective-grounded walk-through of the transaction in plain language: zone-by-zone before/after comparison, shift identification, and a fact-review phase that surfaces miscalibrated conviction levels or incorrect relationships. You can also callforgetimmediately to retract. - Pull-request review. When your repository is set to ingest onto a branch, a PR is opened or updated for the commit. Reviewers you’ve assigned — via the
reviewers:frontmatter field, or your normal GitHub team configuration — review and approve before merge. Both the memory.mdand the extracted.sparqlare in the diff. Thereviewtool is offered alongside the PR as an interpretation layer on the diff, not a replacement for it. When your repository is set to ingest onto its main branch, commits land directly and the synchronous summary and thereviewtool are the review surface. The setting is yours and does not vary by plan.
For hallucinations or misrepresentations introduced by your AI tooling at the drafting step, we defer to the policies of the AI provider you have selected — we operate downstream of that. For extraction issues introduced inside our Platform, the guardrails above apply, and your repository review is the verification point.
5. Output verification is yours, with the tools to make it efficient (output-side trust)
Where you deploy an agent on a channel, every conversation is visible to your designated Operators in real time through the Front operator interface — draft mode, message-by-message intervention, seamless step-in and step-out. Operators are the source of truth on the agent’s behalf and can take any conversation back at any time.
For non-agent uses — perspective queries through MCP, content drafted with the perspective loaded — the cite tool maps every claim in any text against the Perspective and shows you what’s grounded (with provenance — memory, actor, conviction level) and what’s ungrounded. Citation is the trust mechanism for any output you don’t see flow through Front.
For Customers requiring deeper output verification — policy-adherence monitoring, custom verification chains, organization-specific escalation logic, tailored review interfaces — enhanced observability and monitoring is available as an Enhanced Deployment Option (see below).
Subprocessors
| Provider | Purpose | Data handled |
|---|---|---|
| Outseta | Authentication front door, billing | Account metadata only |
| GitHub | Repository hosting (Customer-connected) | Repository content per granted scope; the customer-side knowledge graph lives here |
| OpenRouter | LLM inference gateway | Transient inference calls; routing posture per our Privacy Policy |
| DigitalOcean (New York, US) | Platform hosting (managed Postgres, container hosting, log storage) | Postgres-backed Platform operational stores: share records (pointer-only), tool-call audit rows (structured parameters only), inference usage rows (no content), internal user/account/auth/repo-connection records (via Datomic-on-Postgres); workflow execution records from self-hosted services (submitted content while a run is processed; 14-day default; disabled on single-tenant) |
| Datomic | Internal data layer over the managed Postgres backend, used for user, account, auth, OAuth-token, and repo-connection records | Same as DigitalOcean Postgres entry — Datomic is the modeling layer, not a separate hosted service. The customer-side knowledge graph is not stored here. |
| Front | Channel layer for deployed agents (operator interface, observability, draft mode, override) | Deployed-agent conversations and operator metadata |
| Twilio (via Front) | SMS provisioning and messaging | SMS conversation content and metadata |
| SMTP / Slack (via Front) | Email and Slack channel transport | Channel-specific conversation metadata |
We update this list with reasonable notice. For MSA-covered Customers, the MSA Schedule B governs subprocessor changes.
Customer Controls
- Connection scope. You elect which repositories and workspaces the Platform may access. Our obligations are measured against the scope you connect.
- Operator designation. You designate who supervises deployed agents.
- Real-time observability. Every deployed-agent conversation is visible in your operator interface. You can intervene as yourself at any time.
- Citation and provenance. Each Platform-generated claim links to the underlying memory and actor. Stale or incorrect content is correctable via the
review,forget, and perspective-management tools. - Bring-your-own OpenRouter key. You may supply your own OpenRouter API key so inference for your account is billed and governed under your direct OpenRouter relationship, including the provider and data-policy restrictions you configure there.
Enhanced Deployment Options (Engagement-Grade)
Beyond the standard multi-tenant SaaS deployment, the following options are available under a Statement of Work:
- Single-tenant managed deployment — dedicated Platform instance on customer-dedicated infrastructure, with workflow execution-data persistence disabled so that no submitted content persists on SIC infrastructure, and application logs limited to pointers and metrics. Channel content is governed by the relevant channel-provider terms
- On-premises deployment — Platform components deployed within your own infrastructure, with operational and key management your responsibility
- Zero-data-retention inference routing — our standard account-level posture, made a contractual commitment
- Customer-managed inference — inference routed through inference gateways or model providers other than the standard OpenRouter path (e.g., Azure OpenAI, Vertex AI, self-hosted or on-premises model endpoints). Available in conjunction with a single-tenant or on-premises deployment so the customer-managed gateway integration is scoped to that deployment
- Customer-controlled storage — including GitHub Enterprise Server and equivalents
- Customer-accessible operational logs — log aggregation routed to Customer-controlled systems for direct visibility
- Enhanced data-residency commitments — specific jurisdictional commitments for storage and processing
- Reduced subprocessor reliance
- Enhanced observability and monitoring — organization-specific output verification, policy-adherence monitoring, custom escalation chains, and tailored review interfaces beyond the standard Front operator surface
- Regulatory compliance add-ons — GDPR (Schedule E DPA); other frameworks on request
These exist so that organizations with elevated compliance, sovereignty, or operational requirements can adopt the Platform without compromising those requirements.
Security Practices
- TLS in transit. Standard HTTPS termination at the edge for all customer-facing traffic, with certificates managed via Let’s Encrypt through our reverse proxy. Internal service-to-service traffic within our hosting environment is on a private virtual network, in line with standard cloud-platform practice.
- Encryption at rest. Cloud-provider default encryption at rest applies to managed services (DigitalOcean managed Postgres, GitHub repository storage). Customer-managed encryption keys are not part of the standard offering; organizations with specific key-control requirements should scope an on-premises deployment under an SOW, where key management is held by the customer end-to-end.
- Operational record retention. Retention is bounded by service category, all on SIC-controlled DigitalOcean infrastructure (New York, US): workflow execution records, which include submitted content, at the default 14 days (disabled on single-tenant deployments); share records, audit rows, usage rows, and Datomic-backed user/auth/repo-connection records for the term of subscription; authentication, configuration, and billing metadata for the term plus sixty (60) days post-termination. Specific retention windows can be configured per Subscriber under an Enhanced Deployment Option.
- Access controls on all Platform infrastructure.
- Subprocessor diligence — zero-data-retention and no-training restrictions enforced at the inference routing layer for every account, contractual under an MSA; subprocessor changes communicated with reasonable notice.
- Incident notification — without undue delay, and within 72 hours where required by applicable law.
EU/UK/Swiss Personal Data
Where the Platform is used to process personal data subject to the EU General Data Protection Regulation (GDPR), the UK GDPR, or the Swiss FADP, you are the data controller and SIC is a processor. For engagement-grade deployments processing such data, our Data Processing Addendum (Schedule E to the MSA) applies and includes Article 28 processor obligations and Standard Contractual Clauses for cross-border transfers.
Get In Touch
For specific security questions, custom deployment scoping, or DPA execution, contact us at security@aswritten.ai or legal@aswritten.ai.
Synthetic Identity Co. https://aswritten.ai