The ADEPT Product Loop

A structured method for AI + IoT delivery.

We run engagements as disciplined, evidence-driven loops grounded in Double Diamond, Google Design Sprint, and Scrum — adapted for the specific demands of connected product development. Each phase produces concrete outputs, not slide decks.

Sprint duration 4–6 Weeks
Phases 5 — A D E P T
Governance Integrated, not optional
ADEPT
Delivery Framework

Five phases. Clear outputs
at every stage.

Every engagement begins with alignment on deployment context and ends with a client team that can operate the system independently. The phases below define what happens in between — and what gets produced at each step.

A
Align

Define the operating environment, user need, system boundaries, and success metrics before any build decisions are made. No assumption is carried forward unchecked.

Week 1
Key questions
  • What problem must the system solve, and for whom?
  • What field conditions — power, connectivity, environment — could break it?
  • What does measurable success look like after deployment?
  • What compliance, data privacy, or security obligations apply?
  • Who is responsible for the system once it leaves our hands?
Activities
  • Stakeholder interviews and field context workshops
  • Deployment environment audit — power, connectivity, climate
  • Integration and interoperability mapping
  • Constraint surfacing: budget, regulatory, hardware, timeline
  • Risk register initialisation and scoring
Outputs
Requirements brief
Constraints map
Success metrics definition
Initial risk register
Stakeholder sign-off record
D
Design

Convert assumptions into testable architecture. High-risk decisions are stress-tested against real hardware, real data, and realistic field conditions — before engineering investment is committed.

Wk 1–2
Key questions
  • Which sensor and connectivity options fit the power budget?
  • How does data flow from device to dashboard to decision?
  • What inference approach is feasible on target hardware?
  • What failure modes need to be designed against now?
Activities
  • Sensor and connectivity option evaluation
  • Data flow and telemetry pathway design
  • Power budget modelling and trade-off analysis
  • Model and inference approach selection
  • Rapid prototype and feasibility validation
  • Bill-of-materials assumption review
Outputs
System architecture document
Prototype plan
Bill-of-material assumptions
Validation plan
Updated risk register
E
Engineer

Build the device, firmware, telemetry pipeline, intelligence layer, and observability dashboard. Security provisions and governance controls are integrated from the first sprint — not retrofitted at delivery.

Wk 2–5
Risk controls
  • Security baseline provisions integrated from sprint one
  • Weekly delivery demos against sprint goals
  • Continuous integration and automated tests where applicable
  • Risk register reviewed at each sprint retrospective
  • Change control log maintained throughout build
Activities
  • Firmware development and hardware integration
  • Telemetry protocol and cloud pipeline implementation
  • Edge AI model training, compression, and on-device deployment
  • Observability dashboard and alerting setup
  • Security baseline checklist completion
  • Technical documentation written in parallel with code
Outputs
Working prototype device
Firmware source + build docs
Telemetry pipeline + dashboard
Technical architecture record
Security checklist (completed)
P
Pilot

Deploy the system under realistic field conditions and measure performance against the success criteria defined in Align. The pilot is a rigorous field experiment — not a demo.

Wk 5–6
Key questions
  • Does the system meet the success criteria defined in Align?
  • What failure modes appeared under real field conditions?
  • How did model performance compare to validation benchmarks?
  • What operational burden does the system place on end users?
  • What must be resolved before scale or full deployment?
Activities
  • Controlled field deployment with defined scope
  • Continuous uptime and data quality monitoring
  • Model and inference performance review
  • User and operator feedback collection
  • Security posture check under operating conditions
  • Issue triage and improvement backlog creation
Outputs
Pilot report
Issue log (prioritised)
Performance metrics summary
Model behaviour assessment
Improvement and scale backlog
T
Transfer

Ensure the client team can operate, maintain, and extend the system without ongoing dependency on Sheffy Adey. Operational independence is a design goal from the first session — not a closing formality.

Week 6
Acceptance criteria
  • Client team can execute routine operations without assistance
  • Incident response procedure is documented and understood
  • Model drift monitoring is in place with alert thresholds set
  • Governance documentation is complete and version-controlled
  • Next-phase roadmap agreed and scope-ready
Activities
  • Structured handover sessions with internal team
  • Operational runbook walkthroughs and review
  • Maintenance, update, and OTA guidance delivery
  • Governance pack review and sign-off
  • Scale and next-phase roadmap planning
Outputs
Handover pack
Operational runbook
Maintenance and update guide
Training materials
Next-phase roadmap
5 Structured phases
25+ Named deliverables
4–6 Week sprint window
100% Capability transfer target
Gov
Governance Built In

Security, ethics, and accountability
are not optional modules.

When an AI-enabled system operates in the physical world — controlling equipment, influencing decisions, or processing sensitive data — governance is a safety requirement. We treat it as such from the first design session.

🔒
Security by design

Device security controls are specified during Align and implemented throughout Engineer. We reference the IoT cybersecurity baseline framework (ETSI EN 303 645 / NISTIR 8259) to structure hardware, firmware, and network posture decisions — not as a post-build audit, but as an embedded engineering discipline.

🤖
Responsible AI principles

AI risk management is aligned to the NIST AI Risk Management Framework (AI RMF). We document model purpose, known limitations, intended deployment context, and failure modes. Where a model's outputs influence consequential decisions, we define human oversight requirements and monitoring thresholds before deployment.

📊
Model behaviour monitoring

Production AI systems can degrade over time as sensor conditions, data distributions, or operating environments change. We design drift detection mechanisms into the telemetry pipeline and define alert thresholds during Engineer — so model performance is observable, not assumed.

🔐
Data privacy and integrity

Data minimisation, collection purpose limitation, and access control are addressed in Align and carried through to implementation. For systems handling personal or sensitive data, we document data flow, retention policy, and access structure as part of the governance pack delivered at Transfer.

📄
Documentation as a deliverable

Technical documentation, operational runbooks, and architecture records are written in parallel with development — not assembled at the end. At Transfer, the client receives a complete and version-controlled governance pack that covers system design, security controls, model behaviour, and maintenance procedures.

🔄
Continuous risk management

The risk register is initialised in Align and reviewed at the end of each subsequent phase. New risks identified during Design, Engineer, or Pilot are logged, scored, and assigned a mitigation owner. The register is included in the Transfer handover pack so the client can maintain it independently.

Standards and frameworks referenced

NIST AI RMF ETSI EN 303 645 NISTIR 8259 ISO/IEC 27001 principles OWASP IoT Top 10 GDPR data minimisation IEEE 7000 (ethics by design)

Standard applicability is determined per project based on deployment context, data sensitivity, and regulatory environment. The list above represents the frameworks we draw on — not a compliance checklist applied uniformly to every engagement.

How We Collaborate

Structured checkpoints.
No black boxes.

Weekly sprint demos

At the end of each sprint week, we demonstrate working outputs — hardware, firmware behaviour, dashboard data, or model performance — against the goals set at the start of the week. Stakeholders see progress in real artefacts, not status updates.

Shared sprint board

The delivery backlog, in-progress work, and completed outputs are visible to the client team throughout the engagement. Priorities can be adjusted at sprint boundaries with full visibility of the impact on scope and timeline.

Risk register reviews

The risk register is reviewed at each phase boundary. New technical, operational, or compliance risks are logged, scored, and assigned a mitigation path. Nothing is resolved informally or left undocumented.

Documented decisions

Architecture decisions, trade-offs, and rejected alternatives are recorded in an Architecture Decision Record (ADR). When a design choice has long-term implications — connectivity protocol, data storage approach, model architecture — the reasoning is preserved for future maintainers.

Ready to scope

Map your first
ADEPT loop.

Bring your deployment context and constraints. In a single discovery call, we will identify which phase you need to start from and what the first sprint should produce.

Book a Discovery Call Explore Services

No obligation · typical response within one business day