Skip to content
J·BJon BishopIndependent growth marketer

Conversion and lifecycle

Data-product evaluation

Design a bounded workload evaluation that checks correctness, reconciliation, recovery, freshness and cost.

Open-source skill · format validated

When this is useful

Build a bounded proof-of-value or workload evaluation for a data platform, connector, pipeline, database, analytics, or ML data product. Use for representative data, correctness, freshness, cost, recovery, and approval criteria; not a generic demo or unsupported performance benchmark.

What to bring

Business task, evaluator and approver, current baseline, authorized dataset and environment, workload shape, constraints, and an approved resource envelope.

What you can work toward

An evaluation charter, workload and correctness plan, result table or runnable test plan, cost and access boundaries, and a decision memo.

Data-product version

Agree on the decision, baseline, representative authorized workload, correctness invariants, updates/deletes/late arrivals, recovery, freshness, cost cap, ownership, and cleanup before results. Keep proposed criteria and measured outcomes distinct.

How to use it

Choose the version for your product type and follow its repository installation instructions. Keep the skill folder, references and any assets together. Each skill works on its own; reuse a shared brief when helpful rather than repeating a full intake.

The source follows the open Agent Skills format and is MIT licensed. Live research and execution depend on the tools and permissions available in your host. Preparing a plan or draft does not itself authorize publishing, messaging, spending or production changes.

A starting prompt

Use the data-product evaluation skill for our data products. Our task is [specific task], our supported environment is [environment], and the decision is [decision]. Use these facts and sources: [evidence]. Produce the requested artifact, label unknowns, and do not invent results or perform external actions beyond my authorization.

How to judge the result

Do not invent evaluation results or claim representative scale from a small sample. Never move sensitive records into an unapproved service.

Check that the product-specific version changes the recommendation, the requested deliverable is complete, and proposed tests are distinguished from observed results. Format validation does not establish how a model will perform on your product.

From input to reviewed output

Put it to work

  1. Choose the collection for your product type and install the relevant skill with its bundled references and assets.
  2. Supply the task, supported behavior, existing evidence and constraints that affect the decision. Reuse context already available.
  3. Ask for the concrete deliverable, distinguishing facts, hypotheses, unknowns and any untested instructions.
  4. Check the product-specific acceptance criteria, source claims and next steps before using or publishing the output.

Limits and tradeoffs

Do not invent evaluation results or claim representative scale from a small sample. Never move sensitive records into an unapproved service. No fresh-host model performance is claimed; verify output against your product, evidence and authorized environment.

Related tools and resources

Prefer to write? Send Jon a message.