---
title: Service description
description: The continuous product delivery service of grm.sh: delivery process, Delivery Units, quality terms, production responsibility, assessment, onboarding and suspension.
canonical: https://grm.sh/service
last-updated: 2026-09-17
---

# Continuous product delivery

A single delivery model, applied to the client's backlog on a monthly basis.

## Scope

Requests are submitted on a shared board in the client's own words. A description of the architecture, file names or proposed implementation steps is not required.

## Delivery process

1. **Analysis.** An agent examines the source code, the documentation and the recorded production baseline, and proposes the smallest independently deliverable result, together with acceptance criteria, risks, required access and the number of Delivery Units. A human operator reviews the proposal before it is issued. Product questions are raised once, in a single round.
2. **Brief.** Approval of the Delivery Brief fixes the definition of completion for that request.
3. **Queue.** Approved items are held in a single ordered queue and may be reordered until an item becomes active. One request is active at any time.
4. **Build and review.** Agents implement and test the change. A separate reviewer verifies the result against the Delivery Brief and against the code change itself, and findings are corrected before delivery to staging.
5. **Acceptance.** The working result is delivered to staging with its supporting evidence and is accepted explicitly. Where the client identifies a failed acceptance criterion, grm.sh corrects it under the same request. The change is then released, production is verified, and the next request is activated.

## Delivery Units

A **Delivery Unit** is one independently acceptable change, constructed to reach staging within **24 consecutive calendar hours of activation**, inclusive of planning, implementation, testing, independent review, corrections and the staging deployment. The period commences once the Delivery Brief has been accepted, the item holds first position in the queue, and all required decisions and access have been provided.

Small related corrections are combined into a single unit. A larger feature is delivered across two or three consecutive units, each concluding in a reviewable result. Work that cannot be bounded in this manner is treated as a subproject under a separate plan.

## Quality and remedial work

Each unit carries its own testing. No change is delivered to staging until the build, test and review gates have been passed.

| Condition | Treatment |
| --- | --- |
| A change delivered by grm.sh fails its accepted criteria or impairs previously working behavior | Corrected at no additional charge and without consuming a Delivery Unit. |
| A failure already present on the recorded baseline | Treated as an ordinary prioritized request, except where it causes a critical production incident. |
| An external dependency fails | grm.sh determines the cause, reports it to the client and applies an existing fallback. Responsibility for the dependency remains with its provider. |
| The result conforms to the accepted Delivery Brief and different behavior is subsequently required | Treated as a new request. |

## Production responsibility

grm.sh operates the agreed production platform, comprising deployment and rollback paths, secrets and access boundaries, monitoring, alerting and logs, off-server backups with verified restores, routine maintenance, and incident diagnosis and recovery.

A **critical production incident**, defined as production being unavailable or a core user journey being unusable, takes precedence over the feature queue. Human diagnosis commences within one hour, Monday to Friday, 09:00 to 18:00 UTC, or within the first hour of the next support window. The time required for restoration depends on the nature of the failure and on systems outside the agreed boundary.

## Assessment

The monthly service is preceded by a read-only review of the existing codebase, the infrastructure and a representative set of forthcoming requests. The assessment establishes whether the project fits the standard delivery model, demonstrates how the actual backlog maps into Delivery Units, identifies any stabilization required, and produces a recommended monthly plan together with a specific onboarding plan.

The assessment is included, is not separately charged and does not consume Delivery Units. Where a project cannot enter the standard service safely, grm.sh issues a separate [Stabilization Brief](https://grm.sh/stabilization) or declines the project.

## Onboarding

Following acceptance of the project into the service, onboarding is included, is not separately charged and does not consume Delivery Units. It comprises a reproducible runtime with a recorded baseline, the agreed infrastructure migration with monitoring, backups and rollback, and a written operating policy. Onboarding alters configuration, infrastructure and deployment mechanics. It does not rewrite the client's architecture.

## Suspension and termination

A suspension takes effect from the next billing period. Billing, the allocation of Delivery Units and the production responsibility of grm.sh cease together, while the queue and its context are retained. Resumption includes a health check against the last recorded baseline at no charge. Any drift is scoped before delivery resumes and is addressed, where required, through Delivery Units or a separate Stabilization Brief. Termination likewise takes effect from the next billing period and includes a documented handover.

[Submit an assessment request](https://grm.sh/contact)

---

Canonical page: https://grm.sh/service