Pre-execution check

Use this workflow at the moment a package, repository, Agent or Skill enters a trusted environment.

Resolve the exact artifact

Search the registry by name, repository, source URL or provider identity. Confirm the Page type and canonical destination before reading its scores.

Trust describes support for trusting the subject. Confidence describes evidence quality, coverage, freshness and corroboration. A high Trust score with low Confidence is not equivalent to two high scores.

Inspect origin and lineage

Check the linked Creator, provider verification, repository relationship and available Agent or Skill lineage. Communication identities such as X and Telegram add context; they are not code audits.

Apply your policy

Continue, request human confirmation, reduce permissions, isolate the artifact, require more evidence or stop. Clawdbase supplies inputs; your workflow owns the decision.

Example decision record

{
  "subject": "agent-alpha",
  "operation": "agent_score",
  "trust_score": 82,
  "confidence_score": 90,
  "evidence_checked_at": "2026-08-15T10:00:00Z",
  "decision": "require_sandbox",
  "policy_version": "agent-intake-v3"
}

Manual workflow

Identify the exact artifact

Use an owner/repository pair, immutable Page ID or canonical public Page. Avoid deciding from a screenshot, copied display name or unverified handle.

Confirm origin

Check the repository and Creator relationship. For a Skill or Agent, inspect lineage when forks, templates, generated packages or upstream dependencies could change the risk.

Evaluate the score state

Record Trust, Confidence, last-scored time and whether the evidence is complete. Do not silently treat pending or missing evidence as a low score.

Bound execution

Decide which tools, secrets, files, network destinations and write permissions are available. Prefer a sandbox for unfamiliar artifacts or incomplete evidence.

Record the decision

Store the canonical Page ID, evidence timestamp, policy version, result and reviewer or automation actor. This makes later investigation and policy changes explainable.

Server-side check

Create an Access Key with scores:read, store it outside client code, and call the implemented operation route:

export CLAWDBASE_API_KEY='claw_live_replace_me'

curl --request POST 'https://www.clawdbase.ai/api/clawdbase/operations/run' \
  --header "Authorization: Bearer $CLAWDBASE_API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{
    "operation": "agent_score",
    "subject": "owner/repository",
    "channel": "api",
    "idempotency_key": "intake-owner-repository-20260815"
  }'

A successful response contains the inVerus result, ledger ID, charge source and updated balance. An upstream scoring failure returns 502 and reverses the reservation. Retrying the same logical request should reuse the same idempotency key.

Review triggers

The Page identity does not match the intended artifact.
Confidence is below the workflow's documented requirement.
The score is stale for the planned impact.
Lineage or Creator context conflicts with the expected source.
The artifact asks for broader permissions than the reviewed use case.
The operation fails and no current authoritative result is available.

After the check, use Example application policy to turn these facts into consistent, versioned workflow behavior in your own application.