Ward Technical Evaluation Packet

1 What Ward is, in one paragraph

Ward is an AI analytics and observability platform for multi-store retail. It connects read-only to the systems a retailer already runs, identifies where margin is leaking, attributes a cause, and runs a prebuilt playbook that writes a correction back to the system of record once a named human approves it. A case closes only when the target KPI has measurably moved. Ward comprises four layers: retail observability, an orchestration layer across model providers, workflow automation into systems of record, and the security and data governance around all three.

2 Ownership and responsibility split

Surface	Customer	Ward
Warehouse and source systems	Owned and operated by you, unchanged	Read-only SELECT via a service account you issue
Data residency	Your existing rules govern	No copy is made, so nothing moves region
Model providers	Your contracts, your API keys	Routes across them, holds none of them
Identity and access	Your IdP, your RBAC roles	Consumes SSO/SAML and SCIM, defines nothing
Agent scope and policy	Cedar policy and charters in your repo	Enforces what your repo says at runtime
Write approval	You name the approver role per playbook	Blocks every write until that role signs
Audit record	Streams into your SIEM, your retention	Emits JSONL, keeps its own copy too
The platform itself	Configured by your team after week six	Runs, patches, and supports it

3 Architecture and data handling

Query model: Federated query executed against the customer’s warehouse in place. Supported: Snowflake, BigQuery, Redshift, Postgres, SAP HANA. Additional sources over REST where a system exposes one.
Data movement: No ETL into a Ward-owned database and no second copy of customer data. Data residency is determined by the customer’s existing warehouse configuration and is unchanged by deployment.
Connection method: SaaS, customer VPC, or an on-premise connector. VPC peering and PrivateLink available.
Credentials: One service account per source, issued by the customer, locked to SELECT on schemas the customer names. Revocable by the customer at any time without notice to Ward.
Encryption: TLS 1.3 in transit, AES-256 at rest. Customer-managed keys supported.
Write-back: Disabled by default. Enabled per playbook, gated on a named approver role defined by the customer. Targets include SAP, Oracle Retail, Blue Yonder, Relex, Manhattan, and pricing and promotion engines.

4 Access control and audit

Identity: SSO and SAML against the customer’s IdP. SCIM for provisioning and deprovisioning. RBAC roles map to roles the customer already maintains. Ward defines no separate user directory.
Authorisation: Cedar policies scope every agent by role, tenant, and resource, enforcing least privilege per agent rather than per user.
Policy as code: Cedar policy and agent charters are versioned in the customer’s own Git repository, reviewed and signed through the customer’s existing change process. A scope change is a pull request and reverts the same way.
Agent charters: Every agent carries a written charter declaring scope, sources, allowed actions, owner, and version. Charters are auditable in the same way a job description is.
Audit stream: Every query, model call, approval, and write-back is logged as JSONL and streamed to the customer’s SIEM. Compatible with Splunk and Datadog. Write-back state is captured before and after.
Traceability: Every figure Ward reports is one click from the SQL that produced it, the source tables, and the model card where a model was involved. Any number can be re-derived independently.

5 The model layer

Providers: Model-agnostic by architecture. Anthropic, OpenAI, Gemini, and Ollama are supported, running on the customer’s own API keys and commercial terms. The application addresses an abstraction layer rather than any provider’s API directly.
Routing: Each task routes to the least expensive model that clears the customer’s accuracy threshold, with failover across providers on degradation or rate limiting.
Model changes: Adopting a different model is a configuration change. An eval harness replays the customer’s own test cases against any candidate and reports accuracy, cost, and latency before promotion.
Numerical method: Forecasts and aggregates are computed by classical statistical models: ARIMA, Holt-Winters, Bayesian hierarchical, and gradient-boosted residuals, backtested over 24 months with MAPE attached. The language model frames results it did not compute and does not generate figures.

6 Deployment path and gates

Weeks one through five are read-only. The first write occurs in week six against a single playbook behind a named approver. Each row below is a point at which the customer can stop.

Stage	Customer action	Gate in force
Week 0 Before you commit to anything	Read the packet. Decide whether it clears your bar.	Nothing is connected. No credentials have been issued.
Week 1 Read-only connection	Issue the credentials. Point us at the schemas you want in scope.	Read-only. Ward has no path to write anything, anywhere.
Week 2 First findings on your own data	Read the first cards. Tell us which ones your operators already knew.	Still read-only. Still nothing written.
Weeks 3 to 5 Policy and scope, in your repo	Review the Cedar policy and charters as a pull request. Name the approver role for each playbook you want live.	Write scope stays closed until you merge.
Week 6 First gated write	Pick the first playbook and the person who approves it.	Every write blocks on the approver role you named. Nothing runs unattended.
Day 90 The number, either way	Read the KPI delta and decide.	Month-to-month from here. Thirty days notice, no rollover clause.

7 Documents available on request

All of the following are available before signature, and none of them wait on us. Open the document room: one form, one click-through NDA, and the room opens on the spot.

Data flow diagram, source by source
Cedar policy bundle as it will be deployed against your role model
Network topology and connection method for your chosen deployment
Sub-processor list
SOC 2 Type II status letter (audit underway)
Penetration test summary
Pre-answered security questionnaire
Master service agreement and data processing agreement
Certificate of insurance: cyber and technology errors and omissions, with an AI rider
Reference call with an operator running Ward on their live systems, scheduled while you are still evaluating

8 Commercial terms

Basis: Tier price reflects data complexity and store count. Nothing is metered by seat, token, or query. Renewals match the same scope.
Range: $24K to $240K+ per year plus one-time setup. Most mid-market retailers land on the Connected tier at $60K.
Term: Month-to-month. Thirty days notice to exit. No rollover clause and no auto-renew.
Guarantee: If Ward does not produce insight cards on your data within 14 days of connection, month two is not charged.
Pilot close criteria: Agreed in writing before the pilot begins. If the agreed KPIs do not move by day 90, the pilot ends and the customer retains every artifact produced.

9 Exit

Because Ward holds no copy of customer data and defines no separate identity store, exit does not involve a migration. Customer data has remained in the customer warehouse throughout. Cedar policy and agent charters are already in the customer’s repository. Model provider contracts are held by the customer directly. Disabling the service accounts issued in week one removes Ward’s access completely. Full deletion of anything Ward retains is available on request and is covered in the DPA.