Skip to content

Work / evidence before claims.

Show what can be verified. State what cannot.

This page explains the evidence behind product and delivery claims. CinaGroup currently has no customer case study approved for public use.

Evidence layers.

Different evidence supports different claims.

We separate implementation evidence from deployment evidence and customer outcomes so that a repository, demo, or test result is not presented as a client case study.

01 / Repository and revision

Inspect the implementation.

Public repositories and pinned commits show what was present at a specific revision. They prove code state—not customer adoption or a managed-service SLA.

02 / Test evidence

Reproduce the acceptance check.

Automated checks, fixtures, and reviewable test output connect a claim to a defined behavior and make regressions visible.

03 / Deployment verification

Verify the environment.

A deployment record and production smoke check establish that a reviewed revision reached the named environment at a known time.

04 / Customer-approved case

Publish only with explicit approval.

Names, logos, quotes, outcomes, and metrics require written attribution approval plus linked evidence, methodology, measurement window, and limitations.

Public case library.

No customer case studies are approved for public use yet.

We will not substitute invented customers, third-party logos, anonymous praise, or unsupported outcome numbers. Product repository evidence remains available on each product page while this library is empty.

Current public cases 0 — publication waits for customer approval and complete evidence.
Illustrative workflows Always labelled as examples; never routed or counted as customer evidence.

Publication standard.

A case becomes public only when every claim is reviewable.

Approval covers the named organization, display name, quoted language, evidence links, measurement method, reporting window, and known limitations. Withdrawal removes the case from public routes.

public_case {
  attribution = "approved in writing"
  evidence    = ["repository", "test", "deployment", "customer source"]
  metrics     = "method + window + limitations"
  status      = "public only after review"
}

Need a verifiable scope?

Define the acceptance evidence before implementation.

Bring the workflow, constraints, and environment. We will help define what should be observable at review, release, and production handoff.