Foundation

What makes business data AI-ready?

For the agreed purpose, in-scope business data is AI-ready when it is current, defined, tested, permissioned, traceable, observable and owned. This is not a certification and does not mean every dataset is perfect:

The exact acceptance conditions are engagement-specific and written into the scope or SOW.

Scope

A typical Foundation includes the following.

SOURCES

10 data sources connected

Shopify, Stripe, HubSpot, Klaviyo, Meta Ads, NetSuite—or the systems that matter most to your operations.

Reliable ingestion, retries, monitoring and alerting are implemented according to the requirements of each connection.

REPORTS

5 reports and dashboards

Built around the questions your team actually needs to answer, using shared data and agreed definitions to reduce manual reporting and conflicting numbers.

WORKFLOW

1 production AI or automation workflow

For example, an AI assistant, automated leadership report or operational workflow grounded in your business data.

Final scope, price and timeline depend on source access, connector complexity, data quality, security and procurement requirements, stakeholder availability, documentation needs and operating requirements.

How success is agreed

Each Foundation uses measures that match its tier and intended outcome. The written scope may cover:

• accepted sources, data flows, reports, dashboards or a first bounded capability;
• reporting-preparation time, reconciliation effort, freshness and time-to-answer;
• data-quality exceptions, failed-run visibility and recovery readiness;
• permissions, human review, fallback and runbook completion;
• active use, owner readiness and handoff acceptance;
• client-specific change from the Assessment baseline where evidence supports comparison.

Each selected measure states the baseline or current condition, measurement period, evidence source, owner and review point. Targets apply only as written in the agreement; they are not universal performance, savings, ROI or payback promises.

What we connect

Memory(One) connects the selected sources that support the agreed business outcome and have a workable approved access path.

A source is one place relevant data comes from: a SaaS platform, internal database, ERP, warehouse system, SharePoint site, Google Drive folder, SFTP delivery, webhook, API or spreadsheet export.

Examples include:

• CRM: Salesforce, HubSpot and Pipedrive.
• Billing and finance: Stripe, Chargebee, QuickBooks, NetSuite, Sage and Xero.
• Advertising and growth: Google, Meta and LinkedIn Ads.
• Support: Zendesk, Intercom and Freshdesk.
• Project and operations: Jira, Asana, Linear and Monday.
• Product and analytical data: Postgres, MySQL, MongoDB and BigQuery.
• Commerce and fulfilment: Shopify, warehouse-management systems and logistics platforms.
• Files and custom paths: SharePoint, Google Drive, SFTP, webhooks and custom APIs.

Where standard connectors do not cover the required entities, fields, freshness or controls, Memory(One) can build or extend a connector. Supported patterns can include REST APIs, GraphQL, webhooks, direct database access, SFTP/file ingestion and custom wrappers, subject to access and scope.

Our Operating Philosophy: Five Layers, Two Disciplines

1. Source

Identify the business questions, the systems and fields that can answer them, the owners, access paths and first priorities. A source is included because it supports an agreed outcome, not because it happens to be available.

2. Ingest

Move selected data reliably into the agreed environment. Depending on the source and freshness need, this may use webhooks, scheduled API polling, batch files or change-data capture. Connectors include the retry, reconciliation and visibility needed for production use.

3. Model

Turn source-shaped data into tested business concepts and definitions. SQL, dbt, Python or the client’s approved modelling tools can create reusable views for customers, orders, subscriptions, revenue, workflow cases and other agreed domains.

4. Orchestration

Run ingestion, models, checks and downstream outputs in the right order. Simple schedules remain simple; more complex work can use Dagster, Prefect, Airflow, cloud-native orchestration or an approved equivalent when dependencies, backfills and lineage justify it.

5. AI Interface

Expose a bounded result people can use: a dashboard, report, internal tool, assistant or controlled workflow grounded in the modelled data. Risky or consequential actions retain an appropriate human-approval path.

Across all five layers:

• Trust covers freshness, row volume, schema changes, key-field quality, monitoring, alerts and visible degraded states.
• Identity & Compliance covers least-privilege access, service identities, secrets, sensitive-data boundaries, role-based access, audit logging and offboarding requirements.

Technology and environment

Built around the client’s approved environment

Foundation does not rely on one mandatory vendor stack. We select the cloud, data platform, storage, modelling and orchestration components that fit the client’s existing architecture, operating capability, security requirements and support model.

Cloud and data platforms

Memory(One) can work within an established cloud, warehouse or lakehouse environment, or assemble a focused foundation in an approved client account.

• 
• Snowflake
• Google BigQuery
• Databricks
• Microsoft Fabric

Data infrastructure and orchestration

Depending on the agreed scope, the implementation may use services such as Amazon S3, Redshift, Athena, Glue, Lambda, Step Functions and EventBridge, together with dbt, Python, Dagster, Prefect, Airflow or an approved equivalent.

The architecture remains as simple as the operating requirements allow. More specialised components are introduced only when data volume, dependencies, backfills, governance or operating responsibility justify them.

• Amazon S3
• Amazon Redshift
• Amazon Athena
• AWS Glue
• AWS Lambda
• AWS Step Functions
• Amazon EventBridge

• dbt
• 
• 
• Prefect
• 

AI interfaces and development environments

Approved AI and developer tools can connect to the client’s governed query or semantic layer through scoped interfaces, permissions, logging and human-review controls where required.

This may include Claude, ChatGPT, Cursor, GitHub Copilot or MCP-compatible clients. A .NET/C#-oriented implementation can be used where it better matches the client environment.

• Claude
• ChatGPT
• Cursor
• GitHub Copilot
• MCP-compatible
• .NET / C#

These are illustrative implementation options, not a universal stack commitment or a statement of partnership, certification or endorsement. The written scope defines the selected components, ownership, security requirements, operating responsibilities and support boundary.

What the client receives

Depending on the agreed tier:

• priority-source map and access plan;
• selected connectors and reliable ingestion paths;
• raw, staging and business-modelled data layers;
• agreed definitions and tested business views;
• reports or dashboards tied to real business questions;
• a first controlled workflow or AI interface where included;
• monitoring, alerting and recovery paths;
• permissions and audit behaviour appropriate to scope;
• documentation, runbooks, handoff and agreed post-launch support.

Process

1. Kickoff and priorities — confirm the SOW, business questions, sources, access, owner, environment and acceptance criteria.
2. Map and connect — rank the sources, establish access and make the first agreed data flows visible.
3. Model and reconcile — create tested business views and tie important numbers back to trusted references where available.
4. Build the outputs — ship the agreed dashboards, reports and bounded interface or workflow in usable increments.
5. Add operating controls — complete monitoring, alerts, access controls, runbooks and recovery routes.
6. Handoff and stabilise — train the owner, confirm acceptance and begin any included post-launch support.

What we need from the client

• 2–4 hours per week from the relevant client team during a standard build.
• A named business owner and the people who understand the sources and decisions.
• Credentials or service-account access, source by source, through an approved process.
• Existing definitions, reports and reference numbers used to validate the result.
• Timely security, IT, procurement and stakeholder decisions.
• Known data-residency, privacy, retention, audit and access requirements.
• Agreement on acceptance criteria, priority sources and the post-handoff owner.

Credentials should not be shared through informal channels. Memory(One) works with the client’s approved secrets and access process where possible.

Week-2 Priority Source Guarantee

For qualifying Foundation projects, the priority sources are agreed before kickoff. If the agreed priority sources are not live in the agreed client-approved environment by the end of week 2 for reasons within Memory(One)’s control, the Foundation deposit is refunded.

The written SOW must name the covered sources, access prerequisites, start point, meaning of live and exclusions. Delays caused by missing or incorrect access, client approvals, undisclosed source limitations, third-party outages, security or procurement blocks, or client-requested scope changes are excluded.

Illustrative walkthrough

An operations team wants to know which orders need attention today. Order, billing and support systems hold different pieces of the answer.

1. Source: identify the required order, payment and support records.
2. Ingest: bring current records into the approved environment and flag missing or delayed inputs.
3. Model: define shared order status, payment state and exception rules.
4. Orchestration: refresh the data, run checks and route exceptions in the right sequence.
5. AI Interface: present a daily view showing the affected orders, supporting context, freshness and owner.

Trust controls prevent incomplete data from appearing as current. Identity & Compliance controls limit records and actions according to role. Actual sources, outputs and controls depend on the agreed scope.

When it fits — and when it does not

Related route: Operations

When reliable data exists but teams need daily review surfaces, approval queues, exception handling or workflow control, continue to Operations.

Ready to build the foundation?

Bring the business questions, the first systems, the reports people do not trust and the person who will own the result.

Scope your Foundation