華文

Pack 3: Competence — Care-Giving

A bridge isn't competent because the blueprint is elegant, but because the bridge holds — and continues to hold when trucks cross, winds rise, and inspectors check the bolts.

Tronto insists that "assuming responsibility is not yet the same as doing the actual work of care." Competence is about execution: working code that does what it promised, audited, explainable, and safe-to-fail. And crucially: "to be competent to care is not simply a technical issue, but a moral one." A system that ships broken care with good intentions has failed morally, not just technically.

The illustration's framing: We check the process — not "just trust us," but with transparency and fast community feedback on how care is delivered.

Core ideas

What good competence looks like

From ideas to practice

  1. Derive specs from contracts. Convert Pack 2 engagement contracts into acceptance tests.
  2. Instrument for observability. Emit decision traces with links to sources and receipts (from Pack 1).
  3. Run shadow mode. New policy sees inputs and proposes actions but doesn't act. Compare to human/previous system.
  4. Canary safely. Release to a small, representative group with automatic rollback if drift exceeds bounds.
  5. Audit before general. Conduct independent audit of evals, logs, and guardrails; publish attested report.
  6. Generalize & monitor. Enable for all; watch drift monitors; keep pause wired.
  7. Post-incident learning. Maintain blameless reviews; fixes become tests.

Tools (buildable today)

Flood-bot story: Part III

What could go wrong

Interfaces with other packs

A closing image: the bridge with inspection tags

Imagine a well-kept bridge with inspection tags — date, load test, next check — visible to anyone crossing. Competence is not the absence of failure; it is the presence of proof that someone checked, and will check again.

Previous Next