Skip to content

Use Cases

kadubon edited this page Jun 21, 2026 · 5 revisions

Use Cases

PIC is a general checker for agent-generated or externally collected candidate material. It is most useful when a workflow needs structured evidence, visible missing work, and a safe next routing decision.

LLM Output Checking

Use PIC when an LLM answer should not be trusted as completed work by default.

PIC can turn output text into a report that separates:

  • the candidate claim;
  • attached evidence;
  • missing evidence;
  • proof obligations;
  • residual ledger entries;
  • recommended next checks.

This is useful for coding agents, research agents, support agents, and RAG systems that need audit-friendly output.

AI Agent Workflow Verification

Use PIC inside a workflow when each agent step should leave a machine-readable trail.

PIC helps answer:

  • What did the agent claim?
  • Which evidence was used?
  • Which verifier route is needed?
  • Is the result operationally usable?
  • Which obligations remain unsettled?

This is workflow verification, not automatic proof of correctness.

GitHub Actions

Use PIC in GitHub Actions when CI should check AI-generated output without mutating the repository.

The recommended CI pattern is read-only:

  • run pic agent check --compact or pic agent intake;
  • upload the JSON report as an artifact;
  • preserve missing obligations and residual ledgers;
  • avoid treating report generation as proof that the PR is correct.

See the repository's GitHub Actions integration docs and copyable example workflow for the maintained pattern.

OpenClaw / ClawHub

PIC can support OpenClaw-style agent safety workflows through a separate skill integration.

The pic-residual-guard skill uses PIC ideas as a pre-action checklist for external-effect actions. It keeps proposed shell commands, file writes, network requests, skill installs, and other actions as candidate work until evidence, risk, host policy, and rollback are reviewed.

PIC itself still does not execute actions or grant authority. OpenClaw sandboxing, allowlists, permissions, and tool policy remain separate controls.

Related project:

Agent-To-Agent Message Checking

Use PIC when one agent receives a message from another agent and needs to decide whether the message can become a packet candidate.

PIC can inspect:

  • message structure;
  • signatures and identity context;
  • nonces and replay risk;
  • provenance;
  • candidate packet content;
  • residual obligations.

Production or adversarial profiles require accepted identity context before signed messages can contribute to packet promotion or collective certificates.

The practical v0.4.4 path is local inbox relay:

pic agent message send --inbox inbox.json --sender agent:alice --text "Candidate packet: preserve residuals."
pic agent message receive --inbox inbox.json
pic agent inbox verify --inbox inbox.json

Reusable Abstraction Capital

Use PIC's ALT layer when a trace, output, or pattern might become reusable work.

PIC asks whether reuse still has positive value after validation, transport, maintenance, depreciation, hazards, and residual obligations are counted. Raw content is candidate material, not capital.

External Knowledge Intake

Use PIC for local files and explicitly supplied live sources such as feeds, web pages, repositories, and structured files.

External content remains candidate material until downstream verifier, semantic edge, identity, rollback, and residual policies accept it.

In v0.4.4, a supplied HTTP/feed source is live-capable by default but remains bounded and candidate-only. Use --no-allow-live-connectors to force a local-only dry run.

Optional Sidecar Diagnostics

Use v0.4.4 sidecars when a workflow needs extra reports without changing the core runtime state:

  • adoption sidecars for handoff documents;
  • packet exchange sidecars for inert packet files;
  • phase dashboard sidecars for observation;
  • benchmark-suite sidecars for protocol-relative diagnostics;
  • autonomy audit for checking that adoption and approval state are not core blockers.

Sidecars are useful for coordination, but they are not approval gates and they do not set settled=true.

Clone this wiki locally