Operations

What Operations is

Foundation connects sources, creates reliable data flows, models business concepts and ships the first reports, dashboards or controlled workflow. Operations is the next layer when teams need purpose-built applications and governance surfaces to use that capability every day.

It is a custom project, not a generic BI dashboard, monthly maintenance plan or SaaS subscription. The operating layer is shaped around the client’s workflow, roles and controls, and is built in the client’s AWS account or another agreed client-approved environment.

Keep the routes distinct

A dashboard that only reports what happened is not automatically Operations. Operations fits when users need a custom action and control layer and the operating complexity justifies a substantial build.

When it fits — and when it does not

What can live in the operating layer

• Operating dashboards with status, drill-down, freshness and ownership.
• Task and review queues that show what needs attention and why.
• Approval paths for AI-assisted or consequential work.
• Exception handling with owners, escalation, fallback and reconciliation.
• Internal tools that let authorised users act on trusted data.
• AI review surfaces for extraction, classification, summarisation or recommendations.
• Workflow controls for long-running steps, retries and handoffs.
• Audit and decision trails that show who changed or approved what.
• Monitoring views for stale data, failed jobs, queue state, model usage and operating cost.

Examples can include a daily KPI brief, an operations command surface, a grounded analysis interface, account-risk review, fulfilment exceptions or campaign and creative analysis. These are patterns, not fixed products; each engagement is scoped around the operating problem.

How success is agreed

The SOW selects measures for the actual operating layer. Depending on scope, these may include:

• accepted surfaces, workflow states, review and approval paths, exception routes, logs, runbooks and handoff;
• queue age, approval turnaround, exception-resolution time, completed outcomes and recovery time;
• human overrides or rejections, workflow throughput and operating cost;
• active use by role, task completion, review participation, owner readiness and fallback use;
• client-specific change from the Assessment baseline in elapsed time, touch time, backlog, exception handling or decision/action time.

Guardrails remain visible: approval bypass, unowned exceptions, unlogged material actions, role or access breaches, unsafe stale state and missing rollback or fallback cannot be averaged away by a positive metric. Targets and acceptance apply only as written in the SOW and are not universal performance or ROI guarantees.

How are AI-assisted workflows kept under control?

The operating layer makes roles, allowed actions, human-review points, source context, logs, cost visibility, monitoring, rollback, fallback and the accountable owner explicit. The exact controls follow the workflow and written scope; this is not a universal security, compliance, uptime or performance promise.

Detailed identities, permission matrices, thresholds, state transitions, recovery steps and cost limits remain in the internal specification and written SOW.

Technical capabilities

Depending on scope, an Operations build can include:

• React or another approved front-end for internal applications and review surfaces;
• Lambda services, APIs and infrastructure-as-code in the client environment;
• Step Functions or another approved orchestrator for long-running and multi-step workflows;
• request envelopes, typed inputs and structured outputs for AI-assisted work;
• prompt traces, response logs, per-call cost tracking and evaluation harnesses;
• role-based and row-level access, approval state and audit logging;
• multi-account or multi-environment isolation where brands, teams or security boundaries require it;
• CI/CD, monitoring, alerting, drift checks and documented runbooks;
• source and model lineage so users can see the data behind an operating decision.

The selected architecture follows the client’s approved stack and ability to operate it. Technical detail, ownership and handoff are defined in the written SOW.

What the client receives

Depending on scope:

• working operating surfaces and workflow controls;
• tested role, review, approval, rejection and exception paths;
• permissions, source context and audit behaviour;
• monitoring, alerts, runbooks and recovery instructions;
• source code and infrastructure-as-code in the client-controlled repository where agreed;
• deployed capability in the client-owned or client-approved environment;
• documentation, acceptance evidence and team handoff;
• 60–90 days of hypercare for larger builds where explicitly scoped;
• a route into Post-Launch Support & Improvement when ongoing maintenance is wanted.

What we need from the client

• A stable or planned data foundation and access to the required business views.
• Named process owners, decision owners and representative users.
• Current workflow states, exception types, manual fallbacks and approval rules.
• Role, access and sensitive-data requirements.
• Examples of the records, decisions and failure cases the surface must handle.
• Timely feedback on working increments and acceptance criteria.
• A team or owner prepared to operate the result after handoff.

Illustrative operating flow

An internal team reviews submitted requests before a downstream action is allowed.

1. A request enters a queue with trusted source context and freshness shown.
2. Low-risk, complete requests follow the agreed path.
3. Consequential or uncertain requests pause for a named person to approve, reject or correct them.
4. Incomplete or failed requests move to an exception queue with an owner and manual fallback.
5. The outcome, decision and supporting context are recorded.

The actual workflow, automation boundary and approval rules depend on the agreed risk model and scope.

Ownership

Engagement-specific source code, services, schemas, infrastructure definitions, runbooks and operating surfaces are delivered into the client-controlled repository and approved environment as defined in the SOW. Memory(One) retains generic methods, reusable patterns and pre-existing tooling.

This ownership model is distinct from the Managed Automation platform and licensed managed configuration.

Related route: Post-Launch Support & Improvement

After a project is live, use Post-Launch Support & Improvement when the need is monitoring, fixes, connector maintenance and agreed improvements rather than a new operating-layer phase.

Ready to discuss the operating layer?

Bring the daily workflow, the people who use it, the decisions they make, the exceptions they handle and the data already available.

Discuss Operations