Skip to content
BranchesTags

Repository files navigation

Data Product Publish Readiness

An OpenClaw-compatible, REST-only prototype that evaluates an IBM Data Product Hub draft before marketplace publication. It collects IBM metadata, ODCS contract evidence, assets, business terms and classifications; applies a controlled readiness taxonomy; produces an evidence-backed report; previews a GitHub issue; and creates that issue only after explicit human approval.

Version 1.0 cannot modify or publish IBM resources. It can generate a non-executable proposed remediation file for owner review.

Why this exists

Data-product publication is often treated as a metadata-completion exercise. A product can have a name, an owner and an asset yet remain difficult to understand or unsafe to reuse. This prototype acts like a pre-publication investigation skill:

  1. retrieve the draft and its governed context;
  2. assess fitness for a stated consumer and task;
  3. distinguish observed evidence from missing evidence;
  4. route findings to the appropriate owner role;
  5. record the result in GitHub after approval.

Architecture

flowchart TD
    A[OpenClaw skill] --> B[Python CLI]
    B --> C[IBM IAM]
    B --> D[Data Product Hub REST]
    D --> E[Draft and ODCS contract]
    D --> F[Assets and IBM glossary]
    E --> G[Controlled readiness assessment]
    F --> G
    G --> H[Evidence and report]
    H --> I[Issue preview]
    I -->|APPROVE ISSUE| J[GitHub issue]
    H --> K[Non-executable patch proposal]
Loading

v1.0 scope

Capability Included
IBM Cloud IAM authentication Yes
Search Data Product Hub drafts Yes
Retrieve one draft and ODCS v3 contract Yes
Retrieve asset metadata Yes
Retrieve IBM business terms and classifications Yes
List glossary evidence in every GitHub issue Yes
Controlled readiness taxonomy Yes
Markdown and JSON reports Yes
Approval-gated GitHub issue Yes
Proposed draft remediation Local proposal only
Modify or publish an IBM draft No
Third-party glossary integration No
MCP server No

Prerequisites

  • Python 3.11 or later
  • an IBM watsonx.data intelligence SaaS account with Data Product Hub access
  • an IBM Cloud IAM API key
  • OpenClaw for the agent workflow
  • GitHub CLI (gh) authenticated for issue creation

1. Create the IBM Cloud API key

The key is created in IBM Cloud IAM, not inside the Data Product Hub page.

  1. Sign in to watsonx.data intelligence with your IBMid.
  2. Open IBM Cloud API keys with the same IBMid.
  3. Select Create an IBM Cloud API key.
  4. Name it openclaw-wdi-readiness-v1.
  5. Copy or download the value immediately; IBM displays it only at creation time.

For a local prototype, a personal key uses your existing access. For persistent or shared deployment, prefer a dedicated Service ID with minimum required access.

2. Install

git clone https://github.com/gprzybycien/data-product-publish-readiness.git
cd data-product-publish-readiness
python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install -e ".[dev]"

3. Configure the terminal session

export WDI_BASE_URL="https://api.dataplatform.cloud.ibm.com"
export WDI_API_KEY="your-ibm-cloud-iam-api-key"
export GITHUB_REPO="gprzybycien/data-product-publish-readiness"

Do not commit these values. If OpenClaw is started from Hatch in Terminal, export them in that same terminal before starting OpenClaw.

4. Verify IBM access

dpp-readiness auth-test
dpp-readiness catalog-id
dpp-readiness search-drafts --query "*"

auth-test never prints the bearer token. catalog-id verifies access to the default Data Product Hub catalog. The search command returns only draft name, version ID and state.

5. Install the OpenClaw skill

From the repository root:

openclaw skills install ./skills/data-product-publish-readiness --as data-product-publish-readiness
openclaw skills list

OpenClaw workspace skills are normally installed under ~/.openclaw/workspace/skills. Start a new chat if an existing session does not refresh its available-skills snapshot.

6. Run an assessment directly

dpp-readiness run \
  --name "Daily Order Fulfilment Performance" \
  --consumer "Regional operations manager" \
  --task "Identify orders likely to miss their fulfilment SLA" \
  --criticality "Operational decision support; daily use" \
  --output-base artifacts

The command creates a timestamped directory:

artifacts/<timestamp>-<product>/
├── evidence.json
├── readiness-report.json
├── readiness-report.md
├── github-issue-preview.md
└── proposed-draft-update.json

proposed-draft-update.json contains placeholders and owner roles. It is intentionally not an IBM API payload.

7. Run through OpenClaw

Example prompt:

Use data-product-publish-readiness.

Assess the draft "Daily Order Fulfilment Performance" for a regional
operations manager who needs to identify orders likely to miss SLA.
Criticality: operational decision support, used daily.

Mode: ASSESS_ONLY.
Do not modify IBM resources or GitHub.

Then ask:

Preview a GitHub issue for the findings in
gprzybycien/data-product-publish-readiness.

Inspect the complete preview. Only then respond with the exact phrase:

APPROVE ISSUE

OpenClaw will invoke the approval-gated command. The CLI independently regenerates the expected issue body from the JSON report and refuses creation if the supplied preview differs.

Readiness taxonomy

The packaged taxonomy is in src/dpp_readiness/readiness_taxonomy.json.

Every generated report and GitHub issue includes a Business Glossary checks section. For each product asset it lists the assigned business terms and classifications, their artifact IDs, and whether each assignment resolved uniquely through IBM Global Search. This proves assignment and canonical resolvability; it does not assert that a term is approved, correct for the intended use, or sufficient for enterprise policy.

It initially evaluates:

  • purpose;
  • accountable ownership;
  • business-term assignment;
  • ambiguous governance artifacts;
  • classifications;
  • ODCS contract presence;
  • quality commitments;
  • delivery configuration;
  • consumer usage guidance.

Decisions are:

  • READY
  • READY_WITH_CONDITIONS
  • BLOCKED
  • INSUFFICIENT_EVIDENCE

The rules are transparent heuristics for this prototype, not IBM product policy. Avoid converting the findings into a single opaque score.

REST operations

The implementation follows current IBM REST patterns:

Evidence Operation
IAM token POST https://iam.cloud.ibm.com/identity/token
Default Data Product Hub catalog GET /v2/catalogs/ibm-default-hub
Draft search POST /v3/search with draft and catalog filters
Draft GET /data_product_exchange/v1/data_products/-/drafts/{version}@{catalog}
ODCS contract GET .../contract_terms/{id}/format?format=odcs&format_version=3
Asset GET /v2/assets/{asset}?catalog_id={catalog}
Attached IBM semantics read-only POST /v3/search

IBM references:

The IBM repository is referenced as executable documentation of REST calls; this project does not install or use its MCP server.

Security boundaries

The REST adapter rejects IBM operations other than:

  • GET; and
  • POST /v3/search, which is used for read-only Global Search.

SaaS mode also rejects a configured API base host outside the dataplatform.cloud.ibm.com domain and validates identifiers before placing them into REST paths.

The client cannot call IBM PUT, PATCH or DELETE. It does not expose draft publication, glossary creation, workflow actions or contract modification.

GitHub issue creation is a separate capability with three controls:

  1. a saved issue preview;
  2. the exact approval phrase APPROVE ISSUE;
  3. a body-integrity comparison against the JSON report.

See SECURITY.md for operational guidance.

Test without an IBM tenant

The repository includes synthetic evidence fixtures.

pytest -q
ruff check .

The tests verify that:

  • IBM write methods are blocked before any network request;
  • draft search includes state and catalog filters;
  • seeded readiness gaps are detected;
  • patch proposals are non-executable;
  • GitHub creation requires exact approval;
  • gh is called without a shell.

No authentic enterprise data or credentials are included.

See the synthetic sample GitHub issue and sample remediation proposal.

Known limitations

  • IBM SaaS response shapes can change; test against a non-production draft first.
  • Contract-test execution results are not retrieved in v1.0.
  • Semantic conflict detection is limited to ambiguous artifact resolution; it does not use an LLM to judge competing definitions.
  • DQ evidence is assessed from contract structure, not source data or runtime quality results.
  • Delivery-method detection is structural and might require adjustment for tenant-specific response fields.
  • The tool recommends remediation destinations but does not assign named people.

Safe path to v1.1 remediation

Draft updating should be added only after confirming the exact supported write endpoint and payload in the target SaaS tenant. A write-capable version should use a separate module and require:

  • a field allowlist;
  • an immutable pre-change snapshot;
  • last_updated or ETag concurrency protection;
  • a field-level diff;
  • approval bound to the draft version ID;
  • one bounded update;
  • read-back verification;
  • no automatic publication.

Until those conditions are implemented and tested, keep proposed-draft-update.json as an owner-review artifact.

Publish this repository

After reviewing the files locally:

git init -b main
git add .
git commit -m "Initial data-product publish-readiness prototype"
gh repo create gprzybycien/data-product-publish-readiness \
  --public \
  --source=. \
  --remote=origin \
  --push

The final command creates an external public repository. Run it only after confirming that no tenant evidence, API keys or local artifacts are staged.

License

MIT

About

No description, website, or topics provided.

Resources

Readme
MIT license

Contributing

Contributing

Security policy

Security policy
Activity

Stars

0 stars

Watchers

0 watching

Forks

0 forks
Report repository

Releases

Packages

Contributors

Languages