A scoped engineering project
The current offer begins with a scoping conversation. We agree a workload, a supported target, quality criteria, resource constraints and the level of evidence needed. The plan can stop at a failed gate; moving a model through every stage is not a substitute for meeting the requirement.
Data and evaluation
Define classes, data splits, evaluation conditions and the measurements that matter to the application. Keep development/calibration separate from independent acceptance.
Model selection and optimization
Compare a public reference with task-specific candidates. Evaluate quality alongside artifact size, target-supported operations and deployment constraints.
Target integration
Investigate exact model/operator compatibility, compiler output, firmware integration and memory use against the selected SDK and board.
Physical evidence
Where the scoped execution path is supported, define controlled board checks and the evidence they need to produce. Separate inference timing from application-level latency, power and reliability.
Availability and evidence
| Capability | Availability | What that means |
|---|---|---|
| Project scoping | Available by contact | Agree one workload, target and deliverable before committing to execution. |
| Keyword model comparison | Public retained evidence | Two integer models evaluated on the same audio. Offline calibration, not independent acceptance or board validation. |
| A10 vision integration | Public retained evidence | A named artifact ran on a physical nRF54LM20B. Its product-quality gate failed. |
| New dataset/model/board work | Subject to project scope | Support, data handling, execution plan, budget and outcome gates must be agreed for the actual request. |
| Paid agent uploads and jobs | Planned; not publicly available | No hosted upload, billing, OpenAPI execution endpoint or MCP server is offered by this website today. |
What a useful deliverable contains
- A clearly identified dataset and model, with the evaluation setting and relevant artifact identities.
- Results against the agreed acceptance criteria, including failed, blocked or unmeasured requirements.
- For deployment work, a traceable relationship between the model, compiler/build and the board evidence actually collected.
- A next decision: advance, revise the data/model, change the target or stop.
Model-file size alone does not establish runtime fit. The same principle applies to evidence: an SDK example or one successful board invocation does not prove a complete application.