01
1. Map the work and the information it needs
Identify the repositories, branches, tickets, documentation and test environments needed for an initial scope. Include dependencies on adjacent services and shared libraries. Give the delivery team enough context to understand the work without assuming every system must be connected.
Separate the information needed to implement a change from the permissions needed to release it. Reading application code does not by itself require permission to modify production systems.
02
2. Agree identities, permissions and revocation
List the engineers, agents and connected services that need access and the operations each must perform. Agree who issues credentials, how they are stored, who can retrieve them and how rotation and revocation will work. Avoid treating a broad repository token as an onboarding plan.
Check the permissions enforced by your repository host. GitHub, for example, documents pull-request review requirements and security controls as part of governing AI-assisted development. The exact controls available depend on your host and configuration. See GitHub’s governance guidance.
03
3. Establish where code and context are processed
Document the models, providers, execution environments and processing locations used for the proposed service. Ask which code, ticket content, logs and documentation are sent to each component, and whether prompts or outputs are retained.
Fusion Standard uses your own AI provider accounts and credentials, so those account terms apply. Fusion Autonomous uses JadeX-managed, self-hosted AI infrastructure. Processing locations, model choices and data flows are agreed during onboarding and security review; self-hosting alone does not establish a data-use policy.
04
4. Confirm model training and confidentiality terms
Ask for the actual data-use commitments that apply to the selected models and configuration. Confirm confidentiality, permitted use and any retention or deletion commitments before providing access. A product label or hosting description does not answer every question about training or logging.
The Fusion FAQ explains the current service boundaries. Existing source code, data and intellectual property remain yours. Ownership of new deliverables and applicable third-party or pre-existing components is set out in the agreed terms.
05
5. Define review, tests and release permissions
Agree acceptance criteria and the review evidence expected for each task. Identify required tests, who investigates failures and who approves changes. Make the release process explicit, including any environments the service may access.
In Fusion, your team retains release control. Human review should distinguish a proposed implementation, recorded test evidence and an authorised release decision.
06
6. Plan the end of access at the beginning
Confirm how repository access and provider credentials will be revoked. Agree treatment of code copies, logs and other service data, plus any retention or deletion responsibilities. Identify the artefacts and context your team needs for continuity.
Customer-specific Engineering Memory created through Fusion Autonomous is owned by you and exportable throughout and beyond the engagement. Confirm export arrangements alongside the rest of the exit process.
07
A useful first-engagement record
- Initial task scope and repository coverage
- Access identities, permission owner and revocation process
- Models, providers, processing locations and data flows
- Confidentiality and data-use commitments
- Required checks, reviewer and release approver
- Retention, deletion and export arrangements
Resolve these points with your engineering and security stakeholders, then start with representative scoped work. This is a planning checklist, not a claim that a particular configuration meets every organisation’s requirements.