Engagement clarity

Security and governance belong in the scope.

A practical checklist for procurement and engineering teams before client code, data, or operational access enters an engagement.

Fitzroy technology assessment and architecture reference illustration
Where we help

Agree the evidence, scope, and controls first.

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

An engagement checklist—not a certification claim.

These are controls and questions to resolve during due diligence and kickoff. The signed agreement governs the engagement. This page is not a substitute for client security review, contractual terms, or applicable legal advice.

Confidentiality and ownership

Agree confidentiality terms, permitted use, background IP, deliverable ownership, and any publication rights in the contract. Public case studies require separate authorization; do not send proprietary material during an initial booking.

Access and environments

Name the authorized systems, environments, people, and access window. Prefer read-only and least-privilege access when sufficient; agree credential handling, access revocation, and whether any production interaction is permitted.

Client data and retention

Document data categories, approved storage locations, transfer channels, retention periods, and deletion requirements. Minimize or redact sensitive samples where possible. Confirm what evidence of deletion is required and what legal retention obligations apply.

AI models and third-party tools

Agree the approved providers, permissible inputs, hosting boundaries, and human-review requirements. Verify training use and retention settings for the specific product and contract. Zero retention is not assumed across all services or configurations.

Changes, incidents, and handover

Set named incident contacts, escalation channels, change approvals, validation gates, and rollback responsibilities. Confirm the handover inventory, runbooks, access revocation, and obligations that continue after delivery.

Robot and physical-system safety

Assign responsibility for hardware access, test supervision, emergency stops, safety qualification, and release authorization. Simulation success is not physical safety certification. Each domain has its own policy artifacts and evaluation gates.

Evidence to request during vendor review

  • Applicable legal entity and contracting details, MSA, NDA, and proposed SOW.
  • Insurance certificates showing actual coverage, limits, dates, and exclusions where required.
  • Applicable security attestations or certifications and their scope, if available.
  • Approved tool/provider inventory and the proposed data-flow and access plan.
  • References available for the engagement, subject to consent and confidentiality.

No SOC 2 certification, insurance limit, universal zero-retention guarantee, or third-party endorsement is asserted here. Required evidence and any gaps should be resolved before access is granted.

Start with Fitzroy

Define the next decision before the next build.

Discuss the system question and the information available. Scope, fee, timing, and contractual terms are agreed before kickoff.