Eyeris vs. The CIO Checklist
Here are the most common questions CIOs ask, along with explanations of how various components of Eyeris’ service address those questions. Just the facts, without marketing spin.
A. Deployment and Sovereignty
A1. Where does Eyeris run?
In the cloud. In all cases, each Eyeris customer is served entirely within a dedicated, single-tenancy “walled garden” – meaning every service, compute, and storage used end-to-end in the data lifecycle resides entirely inside the boundary of that garden. Zero ingress/egress except as explicitly contracted, and zero reliance on external apps or services – including LLM processing. Everything is entirely private and entirely dedicated to a single eyeris customer.
This table provides a summary of the physical architecture beneath each functional layer of the service.
| Layer | Compute | Processing Storage | Continuity |
|---|---|---|---|
| Stella | High-GPU Array | Elastic, Ephemeral | Snapshot to S3/Blob/GCS |
| Luna | High-CPU Array | I/O Optimized, Ephemeral | Snapshot to S3/Blob/GCS |
| Sola - CI Data & Metadata |
Cloud-scale analytic warehouse service | Cloud-scale analytic warehouse service | Snapshot on S3/Blob/GCS |
| - CI Processing | High-CPU Array | I/O Optimized, Ephemeral | Snapshot to S3/Blob/GCS |
| - Data Collection | Light-duty Array | S3/Blob/GCS, Persistent | Replication on S3/Blob/GCS |
A2. Which clouds are supported (AWS, Azure, GCP)?
All three.
A3. Can we pin processing to specific regions for data-residency obligations?
Each client can define the region in which their Eyeris service runs. All layers of the service (Stella, Luna, Sola) run in the same region.
A4. Does any customer data leave our tenancy at any stage?
Never.
B. Data Handling
B1. What data does Eyeris ingest, and what does it persist?
Eyeris uses raw operational data from many sources at the customer. That data can come from databases, cloud applications, data lakes, log streams, and batch processes. It can be pulled actively by Eyeris active collectors or pushed to Eyeris’ passive collectors by system owners at the customer. In all cases, data feeds are governed by signed data interchange contracts that specify the nature, timing, content, and format of transmissions – whether those transmissions are push or pull.
B2. Is raw data copied or processed in place?
Eyeris works with raw copies of source data. We do not use customer-host compute for any of our processing.
B3. What is the retention model, and can we set it?
Each customer specifies in their contract how long Eyeris retains each genre of data. Typically, source data are retained in secure archive for 3 months, Causal Intelligence data are maintained for a rolling 36-60 months, and end-user analytic interactions (conversations, data, charts, reports, etc.) are retained for 60 months.
B4. On contract end, what is the deletion guarantee and timeline?
All data are deleted from active storage and archive storage, and all drives are sanitized by Eyeris prior to returning those machines to the cloud pool, where they are again sanitized by the cloud platform itself.
C. Security Architecture
Stella/Luna/Sola security controls by functional layer are shown in the diagram below
C1. Encryption in transit and at rest?
All data in-flight across the service boundary, including system-to-user and source-to-system transmissions, are encrypted using TLS 1.3. All data on disk are encrypted using 256-bit AES.
C2. Customer-managed keys supported?
CMK is supported as an option, subject to an upcharge and reduced SLAs. Integrated single-dependency processes are inherently cheaper and more reliable, but we recognize that some customer’s operating environments pose unique demands.
C3. Identity model — SSO, SAML/OIDC, MFA, SCIM?
Eyeris supports SSO, SAML/OIDC, and MFA. SCIM is less relevant for the Eyeris stack due to (a) its zero-ingress/zero-egress walled garden architecture and (b) its typical user community of a couple dozen high-impact executives.
C4. RBAC granularity — who can see which causal maps, inputs, outputs?
Access to and rights within each layer of the service architecture are controlled by role. Within Stella, only the user can see their owne conversation history and analytical artifacts unless that user chooses to share those items with another user. Within Luna, only the Analytic Auditor has direct access to workflows for reports specifically shared with the AA by an executive user, and this access is read-only. Within Sola, no client personnel have operational access to the Intelligence Processing layer (Rosetta, iDQ, and Causal Maps), but client DBAs often have read access to the Sola CI repository via the API.
C5. Audit logs — events, retention, exportable to our SIEM?
Eyeris logs every interaction between the system and each user, every data flow checkpoint, and every change in access controls. All logs are available to the customer upon request. Realtime logging into SIEM is usually not necessary, given that the Eyeris service is a zero-ingress/zero-egress walled garden with only a couple dozen high-impact executive users.
D. AI Security
D1. Do LLMs or ML models touch our data? If so, which, with what boundaries?
No public LLM or ML models touch client data. Stella, Eyeris’ LLM, is a private walled garden implementation using an open source semantic model locally installed and managed by Eyeris alone. No calls, dependencies, or trace/audit messages are allowed egress from the walled garden.
D2. Is our data used to train any shared model?
Customer data are not used in any way to train any semantic models.
D3. How are causal inferences validated to prevent silent model drift?
Sola uses a Structured Causal Modeling (SCM) approach, in which the baseline causal maps are defined deterministically by an Eyeris Causal Engineer. This SCM is executed prior to any neural processing and becomes the baseline against which any neural inferences might be applied, mitigating drift by providing a stable baseline of causal expression. Furthermore, neural inference in Stella is constrained to two problem domains: (1) translating natural language expressions of curiosity or analytical interest from the user into an analytical plan that connects that interest to the available CI data resources and (2) interpreting the results returned by the analysis and creating effective communication strategies to ensure the user understands what those data say. The analyses themselves may only be executed by Stella using Luna’s standard deterministic, auditable, traceable, human-interpretable analytic widgets. This architecture radically reduces the opportunity for inference instability.
E. Reliability
E1. SLA?
Each customer contract specifies the cadences of data transmission and intelligence processing for Sola, as well as system availability and performance for the CI API and the user-accessible functions of Stella and Luna.
E2. Backup and disaster-recovery posture — RPO/RTO?
These vary by layer. Please see the graphic in the Security section above for the DR/recovery standards for each functional layer.
·E3. Incident response process and notification SLA?
We notify clients of any incident or failure against any SLA within 2 hours of detection.
F. Integration and IT Fit
F1. Supported source systems and connectors?
| Active Collectors | Passive Collector Standards |
|---|---|
Application-specific Data Integrations
Generic Data Integrations
|
|