Example application policy

Turn Clawdbase evidence into explicit, reviewable workflow rules in your own application.

A policy should combine Clawdbase output with the action's consequences. Installation, read-only research and autonomous production execution should not share the same threshold or permissions.

Recommended inputs

Trust and Confidence values and their scoring timestamp.
Page type, canonical provider ID and verification status.
Creator and lineage context when the subject is an Agent or Skill.
Requested permissions, data sensitivity and execution environment.
Your policy version and the human or service making the decision.

Prefer explicit outcomes instead of a single boolean. A useful illustrative vocabulary is allow, allow_sandboxed, require_review, require_refresh, and deny. The application can then explain what must happen next rather than presenting a dead end. Nothing in this section is a Clawdbase response contract — build and version this logic in your own codebase.

type Decision =
  | { action: 'allow' }
  | { action: 'allow_sandboxed'; restrictions: string[] }
  | { action: 'require_review'; reason: string }
  | { action: 'require_refresh'; maxAgeHours: number }
  | { action: 'deny'; reason: string }

function decide(input: {
  subjectType: 'agent' | 'skill'
  state: 'complete' | 'partial' | 'unavailable'
  trust: number | null
  confidence: number | null
  scoredAt: string | null
  maxAgeHours: number
  canWrite: boolean
}): Decision {
  if (input.subjectType !== 'agent' && input.subjectType !== 'skill') {
    return { action: 'deny', reason: 'unexpected subject type' }
  }
  if (input.state !== 'complete' || input.trust === null || input.confidence === null) {
    return { action: 'require_review', reason: 'evidence unavailable' }
  }
  if (!Number.isFinite(input.trust) || !Number.isFinite(input.confidence)) {
    return { action: 'require_review', reason: 'invalid score evidence' }
  }
  if (!input.scoredAt) return { action: 'require_refresh', maxAgeHours: input.maxAgeHours }
  const ageMs = Date.now() - Date.parse(input.scoredAt)
  if (!Number.isFinite(ageMs) || ageMs < 0 || ageMs > input.maxAgeHours * 3_600_000) {
    return { action: 'require_refresh', maxAgeHours: input.maxAgeHours }
  }
  if (input.trust < 40 && input.confidence >= 70) {
    return { action: 'deny', reason: 'low trust with strong evidence' }
  }
  if (input.confidence < 60 || input.canWrite) {
    return { action: 'allow_sandboxed', restrictions: ['no-network', 'no-write'] }
  }
  return { action: 'allow' }
}

This is an illustration, not a Clawdbase default. Version and test your own policy against real outcomes.

Refresh behavior

Do not silently substitute stale evidence. Show when the score was last calculated, define a maximum age for high-impact decisions, and request a refresh when the record falls outside that window.

Inputs worth versioning

A robust policy normally evaluates more than two numbers:

Input	Why it matters
Canonical Page and Page type	Prevents applying evidence to the wrong subject
Trust and Confidence	Captures evidence direction and strength
Score state and timestamp	Distinguishes current evidence from pending or stale evidence
Verification method	Shows how source control was established
Requested permissions	Connects evidence to the consequence of execution
Environment	Separates local experiments from production deployment
Policy version	Makes later decisions reproducible

Adoption sequence

Preserve this progression instead of enforcing a threshold on day one:

Observe first

Run the policy without blocking execution. Compare proposed outcomes with human review and operational incidents.

Add bounded enforcement

Start with the highest-impact permissions or environments. Preserve an auditable override path with a reason and actor.

Monitor drift

Track changes in evidence freshness, unresolved subjects, false positives and manual overrides. Review policy thresholds as outcomes accumulate.

Failure defaults

Choose failure behavior deliberately. A read-only local workflow may fall back to a sandbox, while production credential access may require current evidence and fail closed. Never convert an unavailable score into 0, and never present an infrastructure failure as a negative assessment of the subject.

Where this fits

This page is a Guides/CI-CD-style reference for building a policy layer on top of Clawdbase evidence. It intentionally sits outside the Pre-execution check first-run path so new developers read the observe-first progression only when they are ready to enforce a policy, not on their first evaluation.