Discuss the evaluation
Bring a specific team problem and the agreement questions that matter to your deployment.
Open this resource →Before service access
Settle the participating scope, service responsibilities, data arrangements, and commercial terms for your selected deployment.
This page is a preparation checklist for a pilot discussion. It is not a service contract, subscription offer, or replacement for the agreement supplied for your deployment.
01 / Before service access
A useful agreement names the deployment, participating users, supported releases, and available features. It also identifies the decision the pilot is meant to inform.
For example, fictional Harbor could name Search and its selected clients. The agreement should describe the actual covered operations rather than imply complete device control.
Identify who may approve configuration and arrange enrollment. Document external accounts and authorizations that participants must obtain separately.
Agree how additional teams, clients, repositories, or services enter scope. A larger evaluation can require a revised operational or data review.
The checklist helps prepare those decisions. Merely reading this page does not create access rights or a promise that a deployment is available.
02 / Before service access
Ask for explicit commercial answers in the applicable agreement. The site does not establish charges, automatic renewal, support response periods, or a service level.
Confirm the deployment and package releases offered for the evaluation. Available source code does not establish that a published service or package is ready.
Assign a contact for setup problems and release coordination. Include the procedure for ending the evaluation while local state or external authorizations remain.
| Agreement item | Details to settle |
|---|---|
| Access period | Start, end and the handling of setup delays |
| Charges | Applicable price, payment arrangements and included work |
| Support arrangement | Eligible requesters, contact channels and agreed commitments |
| Release maintenance | Supported versions and responsibility for upgrades or configuration changes |
| End of evaluation | Access removal and action on credentials, records and local state |
| Operational incidents | Contacts, communication responsibilities and response arrangements |
03 / Before service access
Set out permitted data use, access, hosting, retention, deletion, and required privacy documentation. Include enrollment identities alongside the runtime report inventory.
Required unknown-repository reporting is separate from optional telemetry. Confirm the organization setting before participants connect their devices.
Native clients and model providers retain their own terms. GitHub and MCP services also require independent permission and data review.
Tally handles the separate pilot inquiry flow. Supply only the details needed for the discussion through that service.
Betterloop enrollment does not confer a provider subscription, GitHub permission, or authorization to another service. Participants need those arrangements independently.
04 / Before service access
Connect acceptance checks to supported actions, client versions, and lifecycle events. Implementation support does not prove that every enrolled device activated its integration.
Instructions remain guidance, and client reports remain operational records. They neither attest a machine nor establish complete observation of its work.
Name the decision owner and retain unresolved gaps with the result. Use the final agreement to settle responsibilities rather than inferring commitments from feature descriptions.
This page does not create a contract. Review and agree the terms provided for the selected deployment before using the service.
Resolve them in the applicable agreement with Betterloop. This checklist does not invent commercial terms, retention periods, or service levels.
Prepare your first rollout
Bring a repository and a concrete requirement. Agree on the checks that will determine your next step.