PnR: Proof of Non-Response

PnR stands for Proof of Non-Response. It is a concrete product track derived from IdeaFirst standalone winner IDEA-20-17-06.

Repository purpose:

Give a first-time engineer or AI worker enough context to run, inspect, and extend a working MVP for measuring non-response as accountability evidence.

Core thesis:

When a credible warning is issued, silence, delay, and deflection are accountability evidence.

PnR turns warning notices into a machine-readable non-response index. It is designed for governance-phase domains where many actors can plausibly claim "not my jurisdiction" after a risk event: space traffic, AI-bio deployment, cross-border telehealth, digital currency standards, chokepoint insurance, robotics safety, and similar multi-actor systems.

The Problem

Most accountability systems begin after harm occurs. PnR starts earlier:

1. A credible warning is issued.
2. A responsible actor or coordination body is identifiable.
3. A response deadline exists or can be inferred.
4. The actor responds, delays, deflects, or stays silent.
5. That response behavior becomes evidence.

The important shift is that non-response is not treated as missing data. It is classified, scored, and preserved for audit.

Mental Model

Think of PnR as a lightweight "receipt system" for risk warnings.

warning notice
  -> expected actor
  -> deadline
  -> observed response
  -> proof class
  -> non-response score
  -> actor rollup report

This MVP does not decide legal fault. It ranks which warning events deserve attention because the response pattern itself is suspicious, harmful, or systemically revealing.

What It Ingests

PnR reads CSV event records. Each row is one warning-response event.

Required concepts:

• a warning source
• the actor that should respond
• response deadline
• response timestamp or silence
• response quality
• risk severity, evidence strength, jurisdiction complexity, and impact scale

See non_response_schema.yaml for the complete field contract.

What It Produces

• event-level non-response scores
• actor-level rollups
• proof classes such as silent_non_response, late_response, deflective_response, and adequate_response
• a Markdown accountability report

Output files are JSON for machines and Markdown for humans.

Proof Classes

Class	Meaning	Example
silent_non_response	no observed response	A regulator receives a safety notice and never replies.
late_response	response after the deadline	An operator replies after the maneuver window has passed.
deflective_response	response exists, but is weak, evasive, or jurisdiction-denying	A body says the risk is outside its scope without naming an owner.
adequate_response	timely response with enough substance	Actor files a mitigation plan before the deadline.

Repository Layout

PnR/
  .pgf/                         PGF design, workplan, and status
  docs/                         engineer and AI onboarding guide
  spec/                         schema and scoring specification
  examples/                     tiny sample input/output
  data/                         dated pilot input data
  tools/pnr_score.py            scoring and report CLI
  reports/                      generated Markdown reports
  results/                      generated JSON scores
  scripts/verify.ps1            end-to-end verification

Read In This Order

For a first-time engineer or AI worker:

1. This README.md.
2. docs/ENGINEERING_GUIDE.md.
3. spec/non_response_schema.yaml.
4. spec/pnr_scoring_spec.md.
5. .pgf/DESIGN-PnR.md if you need the PGF intent.
6. tools/pnr_score.py only after the concept and data contract are clear.

Quick Run

From the PnR folder:

py -3 tools/pnr_score.py `
  --input examples/sample_events.csv `
  --output examples/sample_output.json `
  --report reports/sample_report.md

Run full verification:

powershell -ExecutionPolicy Bypass -File scripts/verify.ps1

Or use the cross-platform verifier:

python scripts/verify.py

Expected verification result:

PnR verification passed

Current Pilot

The dated pilot input is data/pilot_events_20260520.csv. It contains eight synthetic-but-domain-grounded warning events derived from the IdeaFirst context. The generated report is reports/pnr_report_20260520.md.

Current pilot highlights:

• high-scoring non-response appears in AI-bio governance, telehealth licensing, digital currency standards, space traffic, robotics safety, and small-sat regulation.
• adequate responses are intentionally scored lower, even when the domain risk is meaningful, because PnR measures response failure rather than raw danger.

How To Extend

Add a new domain by adding rows to a CSV file with the same schema. Do not add new scoring fields until the existing event contract cannot express the case.

Good candidate events have:

• a named actor
• a dated warning
• a dated deadline
• observable response or non-response
• evidence that the warning was credible
• enough domain context to justify severity and jurisdiction scores
• consistent actor naming inside the file

Poor candidate events are vague complaints, rumors without warning records, or cases where no actor could reasonably respond.

Boundary

PnR is not legal advice, regulatory certification, or production AOX output. It is an exploratory mechanism for converting non-action into auditable evidence before cross-model or institutional validation.

Use PnR outputs as:

• audit prioritization
• investigation queueing
• governance design evidence
• early warning intelligence

Do not use PnR outputs as:

• legal liability determination
• regulatory approval or denial
• investment advice
• safety certification