Example Proposal — Implementation Review / Onboarding

Purpose: Filled example of how we would present the Implementation Review offer to a prospective client. Uses a generic scenario; replace Client Name and tailor context for real use. Not a contract. Source: OFFERIMPLEMEN

Example Proposal — Implementation Review / Onboarding

Purpose: Filled example of how we would present the Implementation Review offer to a prospective client. Uses a generic scenario; replace [Client Name] and tailor context for real use. Not a contract. Source: OFFER_IMPLEMENTATION_REVIEW.md and PROPOSAL_TEMPLATE_COMMERCIAL_OFFERS.md.

Client / project

Client: [Client Name]
Project: AINL Implementation Review — [Project Name or e.g. “Internal workflows / agent automation evaluation”]
Selected offer: Implementation Review / Onboarding

Summary

We propose a structured implementation review of [Client Name]’s use of AINL. We will review your repository (or described setup) against conformance to the language and runtime contract, adapter and ops patterns, and recommended practices, using the same open checklists we use internally. You will receive a short written report and a prioritized success plan with concrete next steps. The engagement is one-time and defined in scope; all referenced documentation and practices remain open. Scope, terms, and pricing will be set out in a separate commercial agreement or SOW.

Client goals

Confirm that current AINL usage (programs, adapters, deployment) aligns with documented contracts and best practices.
Identify conformance gaps, adapter misuse, or missing discipline before scaling or production use.
Obtain a clear, written artifact (report + success plan) for internal or governance use (“we’ve been reviewed”).
Get a prioritized list of next steps to reduce risk and shorten time-to-value.

Current situation / context

[Client Name] is evaluating or has begun adopting AINL for internal workflows and agent automation. The team wants an expert pass over their setup—whether a repo, a described architecture, or a subset of programs and adapters—to ensure they are on a solid footing before expanding use. They prefer a defined engagement with clear deliverables rather than ad hoc advice.

Scope of work

Intake — Agree scope of review (e.g. conformance only; conformance + adapter usage; conformance + ops/monitor patterns), inputs (repo access or written description), and timeline. We may use a short questionnaire or call to clarify goals.
Review — Inspect the provided repo or description against conformance, adapter semantics, and implementation discipline (as in our preflight and conformance docs). Document strengths, gaps, and risks.
Deliverables — Produce a short written implementation review report and a success plan (prioritized next steps). Format and length will be agreed in scope (e.g. 2–4 pages plus checklist).
Handoff — Deliver the report and success plan and, if included in scope, one follow-up call or email thread to walk through findings and recommendations.

Customer responsibilities / inputs

Repo or description — Provide access to the repository (or a representative slice) that uses AINL, or a written description of your setup, programs, and how you run them (e.g. which adapters, which monitors, deployment pattern).
Scope — Confirm what you want reviewed (e.g. conformance only; conformance + adapter usage; conformance + ops/monitor patterns) so we can align deliverables.
Point of contact — Designate one or two people for intake, any calls, and delivery of the report.

Deliverables

Implementation review report — Written summary of: conformance status (e.g. strict vs compatible, key contracts), adapter and ops usage (correct use vs risks), and alignment with recommended practices. Clear “in good shape” vs “should address” items, with references to specific files or patterns where relevant.
Success plan — Prioritized list of next steps (e.g. fix conformance gaps, adjust adapter usage, add validation, update runbook). Actionable and scoped so you can assign and track follow-on work.
Optional — One follow-up call or thread to discuss the report and plan (if included in scope).

What remains open / repo-grounded

All checklists and conformance documentation we use for the review are part of the open AINL project (e.g. BOT_ONBOARDING, OPENCLAW_IMPLEMENTATION_PREFLIGHT, CONFORMANCE, RELEASE_READINESS). You retain full access to these materials. The paid value of this engagement is our time and the structured application of these references to your setup—not access to proprietary documentation. There is no lock-in; you keep full control of your repo and roadmap.

Out of scope

Ongoing support — This is a one-time (or defined-scope) engagement. SLA-backed support, ongoing questions, or incident response are not included unless agreed separately (e.g. as a support plan).
Certification — We do not issue formal certification or credentials as part of this engagement. Certification may be offered later as a separate product.
Implementation work — We review and recommend; we do not implement fixes, new features, or deployment as part of the base engagement. Custom implementation can be scoped separately (e.g. consulting SOW).
Pricing — Not specified in this proposal; to be agreed in a separate commercial agreement or SOW.

Assumptions / dependencies

[Client Name] will provide the agreed inputs (repo access or written description) in time for the review phase.
Scope of review (conformance only vs conformance + adapter/ops) will be confirmed before the review begins.
One primary point of contact will be available for intake and, if agreed, for the handoff call or thread.

Timeline / phases

Phase 1 — Intake and scope confirmation: Confirm scope, inputs, and timeline. [e.g. Week 1 or TBD]
Phase 2 — Review: Inspection of repo or description and drafting of report and success plan. [e.g. 1–2 weeks or TBD]
Phase 3 — Delivery and handoff: Delivery of report and success plan; optional follow-up call or thread if in scope. [e.g. Week 3–4 or TBD]

Exact dates and turnaround will be confirmed upon signed agreement.

Commercial terms

[Commercial terms / pricing handled separately]

Scope, pricing, and legal terms for this engagement will be set out in a separate commercial agreement or statement of work (SOW). This document describes the proposed scope and deliverables only.

Acceptance / next steps

[Client Name] confirms that this scope and these deliverables align with their goals.
[Client Name] contacts us to finalize commercial terms and, if applicable, sign an agreement or SOW.
Upon signed agreement, we will confirm kickoff date and intake details (e.g. repo access or description, point of contact).

Example only. Not a contract. For the full offer and boundaries, see OFFER_IMPLEMENTATION_REVIEW.md. For a blank template, see PROPOSAL_TEMPLATE_COMMERCIAL_OFFERS.md.

Example Proposal — Implementation Review / Onboarding

Client / project

Client: [Client Name]
Project: AINL Implementation Review — [Project Name or e.g. “Internal workflows / agent automation evaluation”]
Selected offer: Implementation Review / Onboarding

Summary

Client goals

Confirm that current AINL usage (programs, adapters, deployment) aligns with documented contracts and best practices.
Identify conformance gaps, adapter misuse, or missing discipline before scaling or production use.
Obtain a clear, written artifact (report + success plan) for internal or governance use (“we’ve been reviewed”).
Get a prioritized list of next steps to reduce risk and shorten time-to-value.

Current situation / context

Scope of work

Intake — Agree scope of review (e.g. conformance only; conformance + adapter usage; conformance + ops/monitor patterns), inputs (repo access or written description), and timeline. We may use a short questionnaire or call to clarify goals.
Review — Inspect the provided repo or description against conformance, adapter semantics, and implementation discipline (as in our preflight and conformance docs). Document strengths, gaps, and risks.
Deliverables — Produce a short written implementation review report and a success plan (prioritized next steps). Format and length will be agreed in scope (e.g. 2–4 pages plus checklist).
Handoff — Deliver the report and success plan and, if included in scope, one follow-up call or email thread to walk through findings and recommendations.

Customer responsibilities / inputs

Repo or description — Provide access to the repository (or a representative slice) that uses AINL, or a written description of your setup, programs, and how you run them (e.g. which adapters, which monitors, deployment pattern).
Scope — Confirm what you want reviewed (e.g. conformance only; conformance + adapter usage; conformance + ops/monitor patterns) so we can align deliverables.
Point of contact — Designate one or two people for intake, any calls, and delivery of the report.

Deliverables

Implementation review report — Written summary of: conformance status (e.g. strict vs compatible, key contracts), adapter and ops usage (correct use vs risks), and alignment with recommended practices. Clear “in good shape” vs “should address” items, with references to specific files or patterns where relevant.
Success plan — Prioritized list of next steps (e.g. fix conformance gaps, adjust adapter usage, add validation, update runbook). Actionable and scoped so you can assign and track follow-on work.
Optional — One follow-up call or thread to discuss the report and plan (if included in scope).

What remains open / repo-grounded

Out of scope

Ongoing support — This is a one-time (or defined-scope) engagement. SLA-backed support, ongoing questions, or incident response are not included unless agreed separately (e.g. as a support plan).
Certification — We do not issue formal certification or credentials as part of this engagement. Certification may be offered later as a separate product.
Implementation work — We review and recommend; we do not implement fixes, new features, or deployment as part of the base engagement. Custom implementation can be scoped separately (e.g. consulting SOW).
Pricing — Not specified in this proposal; to be agreed in a separate commercial agreement or SOW.

Assumptions / dependencies

[Client Name] will provide the agreed inputs (repo access or written description) in time for the review phase.
Scope of review (conformance only vs conformance + adapter/ops) will be confirmed before the review begins.
One primary point of contact will be available for intake and, if agreed, for the handoff call or thread.

Timeline / phases

Phase 1 — Intake and scope confirmation: Confirm scope, inputs, and timeline. [e.g. Week 1 or TBD]
Phase 2 — Review: Inspection of repo or description and drafting of report and success plan. [e.g. 1–2 weeks or TBD]
Phase 3 — Delivery and handoff: Delivery of report and success plan; optional follow-up call or thread if in scope. [e.g. Week 3–4 or TBD]

Exact dates and turnaround will be confirmed upon signed agreement.

Commercial terms

[Commercial terms / pricing handled separately]

Scope, pricing, and legal terms for this engagement will be set out in a separate commercial agreement or statement of work (SOW). This document describes the proposed scope and deliverables only.

Acceptance / next steps

[Client Name] confirms that this scope and these deliverables align with their goals.
[Client Name] contacts us to finalize commercial terms and, if applicable, sign an agreement or SOW.
Upon signed agreement, we will confirm kickoff date and intake details (e.g. repo access or description, point of contact).

Example only. Not a contract. For the full offer and boundaries, see OFFER_IMPLEMENTATION_REVIEW.md. For a blank template, see PROPOSAL_TEMPLATE_COMMERCIAL_OFFERS.md.

Example Proposal — Implementation Review / Onboarding

Client / project

Client: [Client Name]
Project: AINL Implementation Review — [Project Name or e.g. “Internal workflows / agent automation evaluation”]
Selected offer: Implementation Review / Onboarding

Summary

Client goals

Confirm that current AINL usage (programs, adapters, deployment) aligns with documented contracts and best practices.
Identify conformance gaps, adapter misuse, or missing discipline before scaling or production use.
Obtain a clear, written artifact (report + success plan) for internal or governance use (“we’ve been reviewed”).
Get a prioritized list of next steps to reduce risk and shorten time-to-value.

Current situation / context

Scope of work

Intake — Agree scope of review (e.g. conformance only; conformance + adapter usage; conformance + ops/monitor patterns), inputs (repo access or written description), and timeline. We may use a short questionnaire or call to clarify goals.
Review — Inspect the provided repo or description against conformance, adapter semantics, and implementation discipline (as in our preflight and conformance docs). Document strengths, gaps, and risks.
Deliverables — Produce a short written implementation review report and a success plan (prioritized next steps). Format and length will be agreed in scope (e.g. 2–4 pages plus checklist).
Handoff — Deliver the report and success plan and, if included in scope, one follow-up call or email thread to walk through findings and recommendations.

Customer responsibilities / inputs

Repo or description — Provide access to the repository (or a representative slice) that uses AINL, or a written description of your setup, programs, and how you run them (e.g. which adapters, which monitors, deployment pattern).
Scope — Confirm what you want reviewed (e.g. conformance only; conformance + adapter usage; conformance + ops/monitor patterns) so we can align deliverables.
Point of contact — Designate one or two people for intake, any calls, and delivery of the report.

Deliverables

Implementation review report — Written summary of: conformance status (e.g. strict vs compatible, key contracts), adapter and ops usage (correct use vs risks), and alignment with recommended practices. Clear “in good shape” vs “should address” items, with references to specific files or patterns where relevant.
Success plan — Prioritized list of next steps (e.g. fix conformance gaps, adjust adapter usage, add validation, update runbook). Actionable and scoped so you can assign and track follow-on work.
Optional — One follow-up call or thread to discuss the report and plan (if included in scope).

What remains open / repo-grounded

Out of scope

Ongoing support — This is a one-time (or defined-scope) engagement. SLA-backed support, ongoing questions, or incident response are not included unless agreed separately (e.g. as a support plan).
Certification — We do not issue formal certification or credentials as part of this engagement. Certification may be offered later as a separate product.
Implementation work — We review and recommend; we do not implement fixes, new features, or deployment as part of the base engagement. Custom implementation can be scoped separately (e.g. consulting SOW).
Pricing — Not specified in this proposal; to be agreed in a separate commercial agreement or SOW.

Assumptions / dependencies

[Client Name] will provide the agreed inputs (repo access or written description) in time for the review phase.
Scope of review (conformance only vs conformance + adapter/ops) will be confirmed before the review begins.
One primary point of contact will be available for intake and, if agreed, for the handoff call or thread.

Timeline / phases

Phase 1 — Intake and scope confirmation: Confirm scope, inputs, and timeline. [e.g. Week 1 or TBD]
Phase 2 — Review: Inspection of repo or description and drafting of report and success plan. [e.g. 1–2 weeks or TBD]
Phase 3 — Delivery and handoff: Delivery of report and success plan; optional follow-up call or thread if in scope. [e.g. Week 3–4 or TBD]

Exact dates and turnaround will be confirmed upon signed agreement.

Commercial terms

[Commercial terms / pricing handled separately]

Scope, pricing, and legal terms for this engagement will be set out in a separate commercial agreement or statement of work (SOW). This document describes the proposed scope and deliverables only.

Acceptance / next steps

[Client Name] confirms that this scope and these deliverables align with their goals.
[Client Name] contacts us to finalize commercial terms and, if applicable, sign an agreement or SOW.
Upon signed agreement, we will confirm kickoff date and intake details (e.g. repo access or description, point of contact).

Example only. Not a contract. For the full offer and boundaries, see OFFER_IMPLEMENTATION_REVIEW.md. For a blank template, see PROPOSAL_TEMPLATE_COMMERCIAL_OFFERS.md.