What runs underneath Ediccio. Disclosed.

Ediccio's model layer provides two capabilities: anextract capability that turns a raw signal into structured profile observations, and an embed capability that turns text into vectors for similarity search. Each capability is pinnable per tenant; the default composition is shared across all tenants unless they opt out. The table shows the currently pinned versions; version updates within the same model family ride the silent-upgrade rule under Change notification below.

The fallback is composed: the primary serves every request, and the secondary takes over only when the primary fails with a transient provider error. Both models are independently qualified against the same golden set (the Quality section below).

A better model is a silent product upgrade. You never choose a model, and a model name never appears on a pricing page. We measure quality, and when a change improves it, we roll it out without changing the contract; changes to the disclosed default follow the 30-day notice under Change notification below.

Tenant data and inference both live in eu-west-1 (Ireland) by default. The Bedrock inference calls use the EU-routed inference profile (eu. prefix); the inference does not leave the EU under the default configuration.

The residency claim covers transport, not just storage: the API endpoints (mcp.eu.ediccio.ai, withmcp.ediccio.ai as an alias) terminate TLS in eu-west-1 on a regional front, so tenant data is decrypted only in the EU, including in transit. The data plane carries no CDN.

Two non-EU exceptions are AWS-contract-driven and hold no tenant data: Amazon CloudFront (global edge, serves only the marketing site) and AWS Certificate Manager + Route 53 (us-east-1, DNS + cert plane; CloudFront requires its certificate to be in us-east-1). These are disclosed in the sub-processor list and processed under the same AWS DPA umbrella.

A customer on the bring-your-own-model option (described below) controls the region of their own provider; their region is recorded in the per-tenant DPA addendum.

Every model that ships passes the same golden set: 30 rows across six dimensions (intent, pain, sentiment, preferences, traditional fields, adversarial). The harness and golden set are available for customer review on request, and every number below is reproducible from them with a single command per configuration.

Mistral standalone is below the qualification threshold and is not customer-selectable. It serves only as the secondary inside the fallback composition; the composed fallback matches the primary's score because the secondary only runs when the primary fails. Under nominal load, Claude carries every request.

The two recall misses on the default configuration (one intent, one traditional field) are semantic disagreements between authored golden labels and model readings, not extraction failures. Per-dimension F1 is 1.000 for pain, sentiment, and preferences.

Ediccio acts as a processor under Article 28 GDPR (and equivalent provisions of the UK GDPR, Swiss FADP, and analogous frameworks). The customer is the controller; they bring theend_user_id of every subject. Ediccio's sole sub-processor is AWS (Amazon Web Services EMEA SARL); every service in the product data plane runs within it, under the AWS GDPR Data Processing Addendum incorporated into the AWS Customer Agreement. The full per-service breakdown lives in the DPA sub-processor register, available on request, so this page stays at the sub-processor level and does not churn on every internal architecture change.

AWS does not retain Bedrock prompts or completions for model training or any other secondary use under the AWS Service Terms. Inference for an eu-west-1 caller is served from eu-west-1.

Ediccio commits to give controllers at least 30 days' prior notice of any addition or replacement of a sub-processor, via the contact established in the DPA. The per-service register (which AWS services run where, kept in lockstep with the architecture) lives in the customer-facing DPA package; the architecture decision records behind this page are shared with it on request.

A data-subject erasure is a hard physical delete of the subject's rows from the tenant database, accompanied by a PII-free audit record. There is no crypto-shredding (the bytes are removed) and no soft-delete-then-purge (the operation is atomic). The audit record names the request, the requester role, and a salted hash of the subject identifier, never the subject's identifier itself.

• Erasure SLO. 30 days from the verified request to subject rows no longer reachable in any live store. Active backups are honoured at the next backup-rotation boundary, within the same SLO.
• Backups. 7-day point-in-time recovery + monthly snapshots retained for 12 months. Subject erasures cascade to backups at the rotation boundary.
• Operational logs. Retained 30 days, then auto-purged. Subject identifiers (end_user_id) and raw signal content are never written to logs; PII is scrubbed at source.
• Bedrock telemetry. AWS does not retain prompts or completions for any secondary use.

DSAR endpoints (POST /tenants/{tenant_id}/subjects/{end_user_id}/erasure,POST /tenants/{tenant_id}/subjects/{end_user_id}/export,GET /tenants/{tenant_id}/dsar/{request_id}) are exposed on the Management API. The customer's Consent Management Platform (OneTrust, Transcend, Ketch, or in-house) is the system of record for consent and calls these endpoints from its workflow. We integrate with CMPs; we are not one.

Most disclosures stop at architecture. This one doesn't, because architecture without verification is a guess. Ediccio runs a seven-gate integration-verification stack that asserts the models are still producing the quality this page claims, the request gate still enforces tenant isolation, and the DSAR flow still completes end-to-end against live AWS, not mocks.

Cadence. The non-AWS gates run on every pull request, on every change to the main branch, and on a daily cron. The gates that exercise live inference run as an operator-initiated, logged workflow, and every model or prompt change is re-qualified against the golden set before it ships.

Audit trail. Operator-initiated verification runs are recorded in a dated log kept in version control, available on request alongside the DPA package. As that history accumulates, the availability target in the Availability section below becomes reportable from the log itself, not from an estimate.

Availability and fallback rate are not measurable yet. The verification log needs a sustained stretch of clean history before the numbers stop being noise; the published target lands in this section once the log can back it.

The temporary line: Ediccio is in private beta, so production availability is not yet reportable. The verification cadence above is the closest proxy until then.

Profiles and signals are AI-generated inferences from text, delivered with confidence scores to your systems over MCP. Ediccio does not interact with your end users directly, and it does not process biometric data, so it is not an emotion-recognition system as the EU AI Act defines one (Art. 3(39): inference of emotions from biometric data). Sentiment here is a property extracted from written conversation, like intent or a preference. The transparency duties of Art. 50 that attach to systems interacting with people sit with the agent you build; what Ediccio owes you is inference clearly marked as inference: every observation carries a confidence score and a machine-readable provenance marker on every surface that emits profile content.

The model layer is interchangeable by interface, a standing architectural commitment. A customer who needs to pin a specific provider (for sovereignty, for an existing enterprise contract, for cost reasons) configures the gateway against any OpenAI-compatible endpoint. The customer's provider becomes the customer's sub-processor, not Ediccio's. Pricing in BYO mode is a mechanical model-cost pass-through; the customer sees the pass-through calculation.

The contract is capability-shaped (extract,embed), not provider-shaped. There is no streaming, no tool-calling, no chat surface inside Ediccio's model boundary. Those are deliberate non-features; the boundary is narrow on purpose.

Changes to the disclosed default models or to the sub-processor set are announced to controllers at least 30 days in advance, via the contact established in the DPA. Model-version changes within the disclosed default (Anthropic's Claude moving to a newer Sonnet release, for example) are silent product upgrades unless a different model becomes the disclosed default; if one does, the 30-day rule applies.

A dated diff log of default-model changes lives under this page as it accumulates.