An inspectable assessment approach: establish the baseline, test the explanation, compare options, and define what must be true before implementation.
A technical engagement should have a defined question, named owners, documented access boundaries, and outputs that support a decision.
Written scope and acceptance criteria
Evidence and assumption tracking
Authorized access and approved tools
Named decision owners
Explicit deliverables and exclusions
A readout before the next commitment
For each finding, record the source, observation date, confidence, owner, limitations, and the test that would confirm or disprove it. Recommendations distinguish measured facts, modeled estimates, and untested hypotheses.
Reconcile billing, tags, ownership, and workload inventory; record missing data.
Trace utilization, data movement, storage, scaling behavior, and reliability constraints.
Compare optimization options with implementation costs, risk, and contractual commitments; separate assumptions from measured waste.
Prioritize reversible changes and define cost and reliability checks before any implementation.
Map service boundaries, APIs, data ownership, dependencies, and critical user journeys.
Review selected code, traces, incident history, and deployment practices against the reported constraint.
Distinguish observed bottlenecks from hypotheses; propose tests requiring separately authorized access or load.
Sequence modernization with compatibility checks, data migration controls, and rollback criteria.
Define one workflow, the human owner, permissible data, and a useful success metric.
Map model/provider choices, integration dependencies, access controls, and retention settings.
Design an approved evaluation set, failure categories, human-review thresholds, and operational monitoring.
Recommend go, revise, or stop; identify evidence missing before deployment rather than calling a demo production-ready.
Select one robot, task, and operating domain; define safety constraints and measurable task success.
Inspect simulation fidelity, control interfaces, reward design, and the suitability of RL versus simpler alternatives.
Define domain-specific evaluation, randomized conditions, transfer-gap measurements, and hardware-test prerequisites.
Specify training, AWS pipeline, policy artifacts, edge release, and telemetry boundaries—or recommend not proceeding.
The proposed default is two working weeks: baseline and access agreement, investigation, owner validation, then a decision readout. The SOW governs actual timing. Any code change, hardware test, migration, or production access beyond the diagnostic requires explicit approval and scope.
Download the AI production-readiness checklist →Discuss the system question and the information available. Scope, fee, timing, and contractual terms are agreed before kickoff.
