Remote delivery and the readiness check

Why this comes first

The real risk in remote delivery is not technical difficulty. It is getting stuck and then waiting on the other side. An unprepared implementation tends to lose its time waiting for someone to open the server room, grant an account or approve a firewall rule — not on the model itself.

The readiness check does three things: it settles responsibility boundaries in advance, it tells you what to prepare, and it lets us judge whether this project suits remote implementation or needs on-site attendance. The check costs nothing and does not mean the project has started.

The environment readiness check

These eight items are confirmed one by one in the project plan. Most projects pass in one round; where an item cannot be met, we adjust as described in the next section.

1. Out-of-band management is available

The servers have IPMI, iDRAC or iLO enabled and we can reach it over a channel you provide — or someone on your side can work at the machine when the operating system will not boot.

To confirm: the out-of-band address and an account (read-only is fine, or you run the commands on our behalf), or the on-site contact and their available hours.

2. A technical contact with authority

This person can perform racking, cabling, reseating and disk replacement on site, can open accounts, ports and VPN policy inside your organisation, and stays reachable during implementation.

To confirm: name, role, available hours, and the operations they are able to perform.

3. Remote access

We connect through a VPN or jump host that you manage. We do not ask you to expose a general internet-facing entry point. If your security policy permits no remote access at all, we can deliver offline instead.

To confirm: the channel type and login method; we test connectivity once before implementation and only log in to the servers you nominate.

4. Hardware and network readiness

Servers are racked and powered, the internal network is reachable, clocks are synchronised, and disk and GPU self-tests pass.

To confirm: your contact runs a read-only check script we provide and returns the output.

5. System and driver baseline

Confirm the operating system, kernel version, GPU driver and CUDA version. Where an upgrade is needed, agree a maintenance window first.

To confirm: return the system version information and the nvidia-smi output.

6. How model weights will be delivered

Downloading requires confirming outbound bandwidth and reachability of the model repository. Physical media requires confirming the media type, encryption and any customs or compliance requirements. Where a restricted model or destination is involved, we check this in advance as well.

To confirm: bandwidth and licensing; for offline delivery, who carries or ships the media and who receives it.

7. Remote session and confidentiality rules

Agree what may be displayed in a remote session, whether it is recorded, where logs are stored, and whether logs or screen content may cross a border. Clients with confidentiality obligations — law firms in particular — usually need this written into the contract or an NDA annex.

To confirm: the rules are written into the project plan, with a confidentiality annex where needed.

8. Pilot scope and acceptance method

Decide which two or three real tasks will be used to validate the system, who judges whether they pass, and what evidence counts as acceptance. Writing the criteria down first is what prevents disputes later.

To confirm: the use cases, the deciding person and the acceptance evidence are listed in the project plan.

If an item cannot be met

• No out-of-band management: move to on-site implementation, or provide an on-site contact who can work at the machine.
• No remote access permitted: deliver offline instead. We migrate over physical media — we have offline implementation experience — and keep integrity verification records in the handover documentation.
• Weights cannot be downloaded: use physical media, with handover and customs confirmed in advance.
• No available technical contact: this is a hard precondition. The project waits until that person is in place.
• Insufficient acceptance evidence: script the acceptance tests so your contact runs them and returns the output as written evidence.

If on-site attendance is required

Quoted and scheduled separately per project, including travel and visa lead time. Work already completed remotely is not charged again.

Contract and invoicing

Contracts are signed with 深圳市集思乐科技有限公司 (Shenzhen Jisile Technology Co., Ltd.) and invoiced in CNY (renminbi). Payment terms are confirmed in the project plan.

Next step

If you would like an early view on whether your project suits remote implementation, tell us the target model, the equipment you have, where the documents live and roughly how many people would use the system. There is no need to share confidential material in an initial enquiry.

Phone: +86 139 2521 1225 Email: tianjun@jsle.cn