Trust & Security Overview

aswritten.ai, operated by Synthetic Identity Co. Effective: 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.
(transcripts, documents,              (We never connect to or access these.)
voice memos, internal tickets)
        │
        │ 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.
        │                             This is the canonical source of
        │                             truth. Synchronous review summary
        │                             is returned to your AI session in
        │                             every tier; on a branch, a pull
        │                             request is also opened or updated
        │                             for standard diff/merge review.
        │
        └─→ Operational artifacts     Compiled-snapshot perspective cache
            (in OUR DigitalOcean      (7-day LRU), share records (pointers
            infrastructure)           into your repository, not materialized
                                      content), execution logs (14-day n8n
                                      default), and internal user/auth/
                                      repo-connection records. Eval capture,
                                      where enabled, holds pointers to memory
                                      and transaction files in your
                                      repository plus result metrics — no
                                      Customer content. Pointers depend on
                                      continued repository access: if you
                                      disconnect the repository, the
                                      underlying content becomes
                                      inaccessible from SIC's 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. We never receive — or have access to — source materials

Source artifacts — transcripts, documents, voice memos, recordings, internal tickets — never reach our Platform, and we never connect to the systems where they live. Refinement happens inside your AI tooling under your existing AI provider agreements. Only the structured, refined memory content you approve is committed and submitted to us.

2. Your repository is the canonical Perspective; our server-side caches are derived

The canonical, source-of-truth representation of your organizational expertise (memories, claims, transactions, snapshots) is stored as files in a git repository. You choose where:

Customer-controlled repository (Team and engagement-grade tiers) — Connect your own GitHub, GitHub Enterprise Server, or supported equivalent. The canonical data resides on your infrastructure at all times. We read and write via API; we lose access on termination.
SIC-Managed Repository (Free, Expert, Team default) — A SIC-provisioned GitHub repository under our organization, available as a starting point. Convenient for self-serve users; subject to a release-of-infrastructure-claims posture documented in our Terms. You retain ownership of the content. Migrate to a customer-controlled repository at any time.

Customer-controlled storage on your infrastructure is the default for engagement-grade deployments.

On server-side artifacts. For performance and operations we maintain artifacts derived from or referencing your canonical Perspective in our managed Postgres — the compiled-snapshot perspective cache (7-day LRU), share records (pointer-only: owner, repo, branch/SHA, directory, recipient metadata — no materialized content), and (where enabled) eval capture (pointer-only: pointers to memory and transaction files in your repository plus result metrics — no Customer content) — alongside execution logs (14-day n8n default) and the internal Datomic-backed records that track your account, auth, and repo connections. The perspective cache is rebuildable at any time from your git history; share records and eval pointers 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 cache is not.

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 elimination of server-side derived artifacts entirely — or who require customer-accessible operational logs, eval capture disabled in production, 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, under those providers’ own data policies. We restrict routing to endpoints that do not train on request data.

Need zero data retention? Two paths: bring your own OpenRouter key, so inference runs under your OpenRouter account and the provider and data-policy restrictions you configure there (including ZDR-only routing) — or an MSA, where ZDR-only routing is a contractual commitment.

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 (every tier). 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 review tool for deeper inspection. The review tool 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 call forget immediately to retract.
Pull-request review (when you’ve connected your own repository on a branch — Team-with-GitHub and engagement-grade default). 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 .md and the extracted .sparql are in the diff. The review tool is offered alongside the PR as an interpretation layer on the diff, not a replacement for it.

For tiers without branching (Expert, and Team-default-without-GitHub), the synchronous review surface is the primary one and commits land on main directly.

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 and Managed)	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	Platform hosting (managed Postgres, container hosting, log storage)	Postgres-backed Platform operational stores: compiled-snapshot perspective cache, share records (pointer-only), eval capture (where enabled; pointer-only), internal user/account/auth/repo-connection records (via Datomic-on-Postgres); execution logs from self-hosted services
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 (e.g., ZDR-only routing).
Migration. Managed Repository Content can be migrated to a customer-controlled repository at any time on request.

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
Zero-data-retention deployment — Customer’s account is routed to a Platform instance configured so that no Customer content is persisted on SIC infrastructure: n8n execution data persistence disabled, compiled-snapshot perspective cache disabled (compile is ephemeral per request), application logs (where enabled) contain pointers and metrics only. Available as either a shared ZDR pool (multi-tenant infrastructure, ZDR-configured stack) or a Customer-dedicated single-tenant deployment per SOW. Channel content and LLM inference are not in scope for this option; channel content is governed by the relevant channel-provider terms, and LLM inference is governed by the inference posture in our Privacy Policy — pair with Zero-data-retention inference routing (below) or bring-your-own-key for end-to-end ZDR
On-premises deployment — Platform components deployed within your own infrastructure, with operational and key management your responsibility
Zero-data-retention inference routing — inference restricted to ZDR-qualified endpoints, as 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
Eval capture disable — production capture of Agent invocations for evaluation purposes disabled per Customer election
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 log retention. Retention is bounded by service category, all on SIC-controlled DigitalOcean infrastructure: n8n execution logs at the n8n default (14 days); the compiled-snapshot perspective cache at a 7-day LRU; share bundles 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 — no-training restrictions enforced at the inference routing layer, with ZDR routing available per deployment posture; 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