Knowledge Hub

Practical answers for teams building AI + IoT systems.

Engineering, delivery, security, and governance — explained for technical leads, product owners, grant reviewers, and procurement teams evaluating AI + IoT partnerships.

Sections 6 topic areas
FAQ questions 30+ answered
Audience Technical + buyer
01 / Frequently Asked Questions

Questions we hear before every engagement.

Organised by topic. If your question is not here, bring it to a discovery call — we will answer it before proposing scope.

Engagement and timelines
What does Sheffy Adey actually deliver? +
Documented, working systems — not slide decks or proof-of-concept demos. Every engagement ends with a defined set of deliverables agreed before work starts: architecture briefs, firmware, pipelines, dashboards, runbooks, security checklists, and handover documentation. The test of a successful engagement is whether the client team can operate the system without us.
How long does a project take? +
It depends on the engagement type:
  • Discovery and architecture sprint: 1–2 weeks. Produces an architecture brief, risk register, and component recommendation.
  • Pilot build sprint: 4–6 weeks. Produces a pilot-capable system, monitoring dashboard, and handover pack.
  • System recovery sprint: 2–4 weeks. Produces a diagnostic report and prioritised recovery plan.
  • Capability transfer: 4–12 weeks depending on system complexity and team size.
Hardware lead times, third-party certification requirements, or grant milestone windows can affect scheduling. We confirm these during scoping.
Can you work from an existing prototype? +
Yes. Many engagements start from a prototype that works in controlled conditions but is not deployment-ready. We assess it against field conditions — power budgets, connectivity assumptions, data quality, security posture, and maintainability — and identify what needs to change before a reliable pilot is achievable. This is also where our System Recovery Sprint is most useful.
What if our pilot is failing or stalled? +
Stalled pilots are a common reason teams approach us. Root causes vary: data quality issues, model performance that does not translate from lab to field, integration gaps, connectivity assumptions that do not hold, or governance blockers. Our System Recovery Sprint starts with a structured diagnostic to identify the actual failure mode — not symptoms — before proposing any remediation work.
What information do you need before a discovery call? +
Three things are most useful before the first call:
  • A short description of the system — what it is supposed to do and what it is not yet doing.
  • The constraint that is blocking progress — technical, resource, timeline, or knowledge.
  • Any existing documentation — architecture diagrams, proposals, test results, grant deliverables.
We do not need a polished brief. A short email with context is enough to prepare a useful first conversation.
Do you work with universities, SMEs, NGOs, or public-sector partners? +
Yes. We work with early-stage teams, research groups, funded programmes, product companies, and public-sector innovation units. Engagement models are flexible — we can work as a delivery partner, a technical reviewer, or a capability-transfer lead depending on what the programme needs. If you are working under a grant or funded programme, see the Buyer and Grant Notes section below.
Technical delivery
Do you build both hardware and software? +
We design and engineer across the full stack — sensor selection, electronics architecture support, MCU/SoC firmware, edge inference, telemetry pipelines, cloud infrastructure, dashboards, and APIs. We work with COTS hardware where available and advise on custom hardware where required, but we do not operate as a PCB manufacturer or volume production facility. Our role is system design and pilot-scale implementation, not mass production.
Do you support edge AI? +
Yes. We design edge inference systems for constrained hardware — MCUs with limited RAM, flash, and compute. That means making real trade-off decisions: which operations can run on-device, at what latency, within what power budget, and with what fallback when inference confidence is low. We use TensorFlow Lite Micro, ONNX Runtime, and Edge Impulse depending on the target platform. We do not deploy cloud models to edge hardware without redesigning them for the constraint profile.
How do you handle connectivity failures? +
We design for them explicitly. On-device store-and-forward buffers, offline detection logic, local alerting that does not require a cloud round-trip, and sync-on-reconnection patterns are standard practice — not add-ons. Connectivity assumptions are documented in the architecture brief so they are visible to operators and maintainers, not buried in firmware assumptions.
Which cloud platforms do you work with? +
We are stack-agnostic and work across AWS IoT Core, Azure IoT Hub, Google Cloud IoT, and self-hosted MQTT brokers. Platform selection is driven by the client's existing infrastructure, compliance requirements, data residency constraints, and cost profile — not by any preferred vendor relationship. We document the rationale for every platform decision in the architecture brief.
Can you work with our existing team and codebase? +
Yes. We can integrate with existing embedded codebases, cloud pipelines, or data infrastructure. During the scoping phase we review what is already in place and scope work to complement it rather than replace it where practical. If existing components are blocking progress, we will say so explicitly and explain why.
Data, AI, and dashboards
How much AI can realistically run on-device? +
It depends on the MCU's RAM, flash, and compute profile, plus the latency and power requirements of the application. On a Cortex-M4 with 256 KB RAM, you can run INT8 quantized models for anomaly detection, keyword spotting, or simple classification — but not large language models or complex vision tasks. We benchmark these trade-offs early in every engagement using the actual target hardware, not generalized estimates. We will always tell you when a task requires a more capable device.
How do you handle model drift? +
Drift monitoring is designed into the intelligence layer — not added retrospectively. We define drift metrics aligned to operational goals, set alert thresholds, and document the conditions that should trigger a model review or retraining cycle. Every intelligence system we deliver includes a monitoring metrics document that explains what each metric measures, what normal range looks like, and what action a drift alert should prompt. This is part of the handover pack, not just dashboard configuration.
What dashboards do you produce? +
We build operational dashboards in Grafana or Power BI (depending on the platform) showing device health, fleet status, inference performance, alert history, and any domain-specific metrics agreed during scoping. Dashboards are designed for the operators who will use them daily — not for demo purposes. We include alerting logic, notification routing, and a panel annotation guide as part of the dashboard deliverable.
Who owns the data and the model? +
The client owns all data, models, and deliverables produced during an engagement. We do not retain data beyond what is necessary to deliver the engagement. IP ownership, data handling, and retention policies are confirmed in writing before work begins. We produce a data classification document during the engagement that records what data is collected, where it is stored, how long it is retained, and who has access.
Security and governance
How do you handle security? +
Security is designed in at the architecture stage — not reviewed at handover. We follow NISTIR 8259 for IoT device cybersecurity baselines and ETSI EN 303 645 for consumer IoT products. Device authentication, secure boot, TLS for data in transit, certificate provisioning, access control policies, and OTA update integrity are standard components of every deployment. A security checklist documenting controls applied and rationale is included in every handover pack.
Are your systems compliant with GDPR? +
We apply privacy-by-design principles to systems that collect or process personal or sensitive data. That includes a data classification step, retention policy, processing record, and access control review. We are not a legal compliance adviser — we do not provide legal sign-off. However, our data handling documentation is structured to support your legal team's review and to meet the technical requirements of a Data Protection Impact Assessment (DPIA) where required.
What governance documentation do you produce? +
Every engagement produces a handover pack that includes: deployment runbook, security and privacy checklist, maintenance guide, incident playbook, access control policy, model card (for AI systems), drift monitoring guide, and operator training session. These documents are written for the teams that will operate the system — not as checkbox compliance artefacts. They are also structured to support grant milestone reporting, procurement due diligence, and internal governance review.
Handover and support
What does handover include? +
A full handover pack covering: deployment runbook, security checklist, maintenance guide, incident playbook, operator training session (recorded or live), model card for AI components, drift monitoring guide, access control policy, and all source code and configuration with inline documentation. Handover is considered complete when the client team has demonstrated they can operate the system without guidance from us — not just when documents are delivered.
Do you provide ongoing support after handover? +
Yes. We offer structured post-handover support windows that cover model drift checks, OTA update management, incident response guidance, and controlled release deployment. Support is scoped and priced separately from the build engagement. The goal is to give internal teams a safety net as they build confidence operating the system — not to create ongoing dependency on us.
Can your systems be maintained by a non-specialist team? +
That is a design requirement, not an afterthought. We write operator runbooks, maintenance schedules, and incident playbooks for the team that will actually use them — which is often not an engineering team. If operational maintenance requires specialist knowledge, we document that explicitly and scope the training accordingly. We will flag during scoping if a system design requires a level of technical expertise the client team does not currently have.
Pricing and scoping
How is work priced? +
Engagements are scoped and priced against a defined deliverable set, not on an open time-and-materials basis. Before any work begins, you receive a written scope document listing every deliverable, the acceptance criteria for each, and the timeline. No open-ended retainers. Scope changes require a written change record — there are no surprise additions to the bill.
Can you support grant-funded projects? +
Yes. Our deliverables are structured to map to grant milestones — including Innovate UK, UKRI, and Horizon-adjacent programmes. Architecture briefs, risk registers, TRL documentation, and technical reports are all part of our standard deliverable set. We can also work to fixed milestone payment schedules aligned to programme reporting windows. If you are building a grant application, a Discovery Sprint can produce the technical architecture and feasibility evidence needed to support it.
Do you offer fixed-price engagements? +
All engagements are fixed-scope, which means the deliverable set and timeline are agreed before work starts. Pricing is fixed against that scope. If scope changes, the price changes — but only after a written change record is agreed by both parties. We do not use variable pricing or time-and-materials structures for standard sprint engagements.
02 / How AI + IoT Projects Work

The stages between an idea and a working deployment.

Most projects fail not because the technology is wrong, but because the transition between stages is managed poorly. Here is what each stage involves and where the common failure points are.

Stage 01
Discovery and architecture

The first stage establishes what the system needs to do, what constraints it must operate within, and what the right architecture is. This includes sensor selection, connectivity strategy, edge vs cloud inference decision, data schema design, and a documented risk register. Skipping this stage or treating it as a half-day workshop is the most common cause of prototype-to-pilot failure.

Stage 02
Prototype and feasibility

A working prototype validates that the core technical assumptions hold. It should be tested against real sensor data, real connectivity conditions, and real power constraints — not a lab approximation. A prototype that only works in controlled conditions is not evidence of feasibility. The output of this stage is a clear decision: proceed to pilot with specific modifications, or revise the architecture.

Stage 03
Pilot build and calibration

The pilot build implements the full system against the architecture agreed in Stage 01. This includes firmware, cloud pipeline, monitoring dashboard, alerting logic, and an initial version of the handover documentation. A calibration period — typically 1–2 weeks — is used to tune thresholds, validate data quality, and confirm that the system behaves as expected under real operating conditions.

Stage 04
Acceptance and handover

Acceptance testing confirms that each deliverable meets the criteria agreed at scoping. Handover includes documentation, a training session, and a period of supported operation. The engagement is considered complete when the client team can run the system independently — including responding to alerts, performing routine maintenance, and managing OTA updates — without requiring external support for standard operations.

Stage 05
Fleet scale and productisation

Scaling from a pilot to a deployed fleet requires additional engineering: OTA fleet management, provisioning automation, cost modeling, multi-tenant access control, SLA instrumentation, and supply chain planning for hardware. This is a different scope from the pilot build and is priced separately. We can support it, but we design pilots in a way that does not create unnecessary rework when scale decisions are made.

Note
Where most projects stall

The most common failure points are: (1) transitioning from prototype to pilot without revisiting architecture assumptions; (2) data quality problems that were not visible at prototype scale; (3) model performance that degrades under real sensor noise or environmental variation; (4) missing governance documentation that blocks procurement or regulatory approval; and (5) handover that leaves client teams unable to operate without continued external support.

03 / Common Deployment Risks

Where AI + IoT projects break down in the field.

Understanding these risks before build is cheaper than discovering them during pilot. Each one is addressable at architecture stage if it is identified early.

Risk
What it looks like
Mitigation approach
Connectivity assumption failure
High frequency
System designed assuming reliable connectivity. In the field, LTE drops, Wi-Fi is unavailable at machine level, or packet loss is higher than expected. Alerts fail to transmit. Data gaps appear in the dashboard. Store-and-forward was not implemented.
Design offline-first from day one. Implement local store-and-forward with configurable buffer. Test connectivity assumptions in the actual deployment environment before pilot sign-off.
Data quality degradation
High frequency
Sensor drift, calibration failures, or environmental interference produce readings that look plausible but are inaccurate. Models trained on clean lab data behave unexpectedly. Alerts fire incorrectly or fail to fire.
Define a data quality validation step in the pipeline. Include sensor health metrics in the dashboard. Implement drift detection on both model output and raw sensor values.
Model performance drift
Medium frequency
Model performs well on test data but degrades over time as operating conditions shift — seasonal variation, hardware aging, or changed process conditions. No monitoring is in place to detect this.
Define drift metrics at architecture stage. Implement monitoring with configurable alert thresholds. Document the conditions that should trigger a model review or retraining cycle in the handover pack.
Power budget overrun
Medium frequency
Device consumes more power than the battery or energy harvesting solution can sustain. Battery life falls short of operational requirement. Devices go offline unexpectedly in the field.
Profile power consumption at firmware design stage using actual sensor and radio duty cycles. Model worst-case and average scenarios. Validate on target hardware before pilot deployment.
Governance documentation gap
Medium frequency
System is technically functional but cannot be approved for deployment because security controls, data handling procedures, or maintenance processes are not documented. Procurement or regulatory sign-off is blocked.
Treat governance documentation as a build deliverable, not a post-build task. Security checklist, data handling record, and deployment runbook should be drafted and reviewed in parallel with system build.
Handover failure
Addressable
System is delivered but the client team cannot operate it independently. Dependency on the delivery team continues indefinitely. Internal support for the system is unavailable when needed.
Design for handover from the start — not at the end. Write documentation for the operators, not the engineers. Include a training session and a supported operation period before closing the engagement.
04 / Security and Governance Basics

What good looks like for AI + IoT systems.

A reference summary for teams who need to demonstrate adequate security and governance controls to procurement reviewers, grant bodies, or internal risk functions.

Device identity
Each device should have a unique, cryptographically verifiable identity provisioned at manufacture or first boot. Shared credentials across devices are a significant security risk — a single compromised device can be used to impersonate the entire fleet. We use certificate-based authentication for all device-to-cloud communication.
Secure boot
Firmware integrity should be verified at boot using a hardware root of trust. Without secure boot, a device can be flashed with malicious firmware through physical access or a compromised OTA channel. This is a baseline requirement referenced in ETSI EN 303 645 and NISTIR 8259.
Data in transit
All device-to-cloud communication should use TLS 1.2 or higher. Unencrypted telemetry over public networks is not acceptable regardless of the sensitivity of the data — metadata about device behavior can be operationally sensitive even if the sensor readings themselves are not.
OTA update integrity
OTA firmware updates should be cryptographically signed and verified before execution. Unsigned updates allow an attacker with network access to push malicious firmware to the entire fleet. Rollback logic should be implemented so a failed update does not render a device inoperable.
Access control
Role-based access control should be implemented for all management interfaces, dashboards, and APIs. Operators, administrators, and read-only users should have explicitly defined permission scopes. All access events should be logged with timestamp and user identity for audit purposes.
AI model governance
Every AI model deployed to a production system should have a model card documenting: what it was trained on, what it is designed to detect, the confidence threshold and fallback logic, known limitations, and the conditions that should trigger a review or retraining cycle. This is a requirement of the NIST AI Risk Management Framework and is increasingly expected by procurement reviewers.
Vulnerability disclosure
A documented process for receiving, assessing, and responding to reported security vulnerabilities should exist for any product with network connectivity. ETSI EN 303 645 requires this for consumer IoT products. We include a vulnerability disclosure policy template in the governance handover pack.
Standards referenced in our work NISTIR 8259 (IoT device cybersecurity capability baseline) · ETSI EN 303 645 (consumer IoT security) · NIST AI Risk Management Framework · IEC 62443 (industrial automation security) · ISO 27001 (information security management) · GDPR (data handling and privacy)
05 / Buyer and Grant Reviewer Notes

What procurement teams and programme managers need to know.

A summary of how our engagements are structured for teams evaluating us through a formal procurement, funded programme, or due diligence process.

Procurement
Everything is scoped in writing before work starts

Every engagement begins with a written scope document listing deliverables, acceptance criteria, timeline, and payment milestones. There are no open-ended retainers. Scope changes require a written change record. This structure is designed to meet standard procurement due diligence requirements.

Grant programmes
Deliverables map to milestone reporting

Architecture briefs, risk registers, TRL documentation, performance reports, and technical handover packs are standard deliverables structured to support grant milestone reporting — including Innovate UK, UKRI, and Horizon-adjacent programmes. We can work to milestone payment schedules aligned to programme windows.

IP and data
The client owns all outputs

IP ownership, data retention, and confidentiality are confirmed in writing before work starts. All deliverables — source code, documentation, models, pipeline configurations — are client-owned. We do not retain data beyond engagement requirements or use client data for any purpose other than delivering the agreed scope.

Technical readiness
TRL documentation is a standard output

Technology Readiness Level documentation is produced as part of the architecture or pilot deliverable set where required. This includes a system description, evidence of performance against requirements, and an assessment of remaining development steps — in the format expected by funded programme evaluators.

Security review
Security controls are documented, not assumed

Every engagement produces a security checklist documenting the controls applied, the rationale for each, and any controls not applied with an explicit justification. This is structured to support internal information security review, procurement security questionnaires, and DPIA preparation where required.

Verification
We are transparent about what is representative

Our case studies are clearly labelled as representative or anonymized. We do not make unsupported capability claims. If a reviewer needs evidence of specific prior work, we discuss what can be shared — subject to confidentiality obligations — before engagement.

06 / Glossary of Key Terms

Definitions for non-specialist readers.

A reference for product owners, programme managers, and grant reviewers who need to evaluate technical proposals or understand project documentation without a deep engineering background.

Edge inference
Running an AI model directly on the device — without sending data to a cloud server first. This reduces latency, reduces data transmission costs, and allows detection to work even without internet connectivity. Requires model compression to fit within the device's memory and compute constraints.
MCU / SoC
A microcontroller unit (MCU) is a small, low-power processor designed to run firmware for a specific function — sensing, controlling, communicating. A system-on-chip (SoC) integrates a processor, memory, and often a wireless radio into a single component. Common examples: STM32, ESP32, nRF9160.
MQTT / LwM2M
Communication protocols used to send data from IoT devices to cloud platforms. MQTT is a lightweight publish-subscribe protocol widely used for telemetry. LwM2M (Lightweight Machine-to-Machine) is a device management protocol designed for constrained devices, including OTA update management.
Telemetry pipeline
The series of steps that move sensor data from a device to a storage or analytics platform: the device sends data, it is received by a cloud broker, processed or transformed, and stored in a time-series database. The pipeline design determines latency, reliability, and cost at scale.
OTA (over-the-air) update
A method of delivering firmware updates to deployed devices without physical access — over the network. OTA infrastructure includes the ability to sign updates (to verify authenticity), roll them out incrementally, and roll back to a previous version if an update fails.
Model drift
The degradation of an AI model's performance over time as real-world conditions shift from the conditions it was trained on. Common causes: seasonal variation, hardware aging, changed operating parameters. Detected by monitoring model output distribution against known baselines.
Model card
A document describing an AI model's intended use, training data, performance characteristics, known limitations, confidence thresholds, and fallback behavior. Required by the NIST AI Risk Management Framework and expected by many procurement reviewers as evidence of responsible AI deployment.
Store-and-forward
A firmware pattern where sensor readings are saved locally on the device when connectivity is unavailable, then transmitted to the cloud when a connection is restored. Essential for systems deployed in environments with intermittent or unreliable connectivity.
TRL (Technology Readiness Level)
A scale from 1–9 used by funding bodies and procurement teams to assess how mature a technology is. TRL 1–3 covers basic research. TRL 4–6 covers laboratory and pilot validation. TRL 7–9 covers operational systems and proven deployment. Most grant programmes require TRL evidence for funded work.
Secure boot
A hardware security feature that verifies the cryptographic signature of firmware before allowing it to run at startup. Prevents malicious or corrupted firmware from executing on a device. A baseline requirement in ETSI EN 303 645 and NISTIR 8259 for connected products.
LoRaWAN / LTE-M / NB-IoT
Low-power wide-area network (LPWAN) technologies used to connect IoT devices over long distances with low power consumption. LoRaWAN uses unlicensed spectrum and is suited to low-data-rate, long-range applications. LTE-M and NB-IoT operate on licensed cellular networks and offer higher reliability and broader geographic coverage.
Fleet observability
The ability to monitor the health, status, and behavior of all deployed devices from a central dashboard — including connectivity status, battery level, sensor health, firmware version, alert history, and inference performance. Essential for operations teams managing more than a handful of deployed devices.
07 / Downloadable Resources

Reference documents — coming soon.

These resources are in preparation. They will be available as free downloads when ready. Register your interest via the contact page and we will notify you on release.

All resources below are placeholders — no download links are active yet
✅
AI + IoT Pilot Readiness Checklist

A structured checklist covering architecture, connectivity, data quality, security, performance, and governance requirements that a system should meet before being considered pilot-ready. Designed for product leads, programme managers, and technical reviewers.

Coming soon · Register interest via contact
🗺️
Sensor-to-Cloud Architecture Brief Template

A structured template for documenting an IoT system architecture — covering device layer, connectivity, data pipeline, intelligence layer, observability, and governance. Suitable for grant applications, procurement submissions, and internal technical review.

Coming soon · Register interest via contact
⚠️
Deployment Risk Register Template

A pre-populated risk register covering the most common failure modes in AI + IoT deployments — connectivity, data quality, model drift, power budget, security, and governance gaps — with mitigation approaches and residual risk ratings.

Coming soon · Register interest via contact
🤝
Capability Transfer Checklist

A structured checklist for evaluating whether an internal team is ready to operate an AI + IoT system after handover — covering system knowledge, operational procedures, monitoring interpretation, incident response, and access management.

Coming soon · Register interest via contact
Start a conversation

Still have questions?

Bring them to a discovery call. We will answer them before proposing any scope — and confirm whether and how we can help with your specific situation.

Book a Discovery Call See Our Services

First call is 45 minutes. No scope is proposed until fit is confirmed.