PINCR RECOVERABILITY FIREWALL

Production authority infrastructure · PostgreSQL first

Production authorityshould be earned.

Before an AI agent or automation receives authority to change production, PINCR proves that the exact proposed action can recover from the current state. If that proof fails, authority never exists.

Recoverability Firewall is the first implementation of a broader primitive for production authority, starting with PostgreSQL.

See the mechanism Run a staging evaluation
TECHNICAL FOUNDATION · DEMONSTRATED

Release evidence green · PostgreSQL, Kubernetes and Linux evidence established

RF / AUTHORITY BOUNDARY DETERMINISTIC OUTCOME
AI proposes → RF proves → Database decides
01 proposal.bound PASS
02 recovery.proven PASS
03 live.state MATCH
04 authority.single_use READY
DECISION Execute exact stored SQL once PERMIT
AGENT CREDENTIAL NONE UNSAFE AUTHORITY REFUSED

AI proposes

RF proves

Protected resource decides

01

Why now

From recommendation to consequential execution.

Write authority needs more than permission.

Identity and policy establish who may ask to act. RF establishes whether this exact action can recover from the current state. As automation gains write authority over production systems, that missing predicate becomes consequential.

  1. 01 Agent or automation

    Proposes a consequential production action.

  2. 02 Identity and policy

    Establish who or what may ask.

  3. 03 PINCR

    Establishes that this exact action can recover from current state.

  4. 04 Protected resource

    Executes once, or refuses.

PINCR sits between permission and execution.

02 · Proof before authority

Prove the recovery path before touching the original.

RF does not ask a model whether a change is safe. It creates a deterministic path from rehearsal on a disposable shadow to enforcement at the protected resource.

01 Propose

Bind the exact action.

An agent, CI system, deploy tool, or engineer submits the precise forward change and recovery path.

02 Rehearse

Prove the way back.

RF runs the change and rollback on a disposable shadow, then checks what recovery actually restored.

03 Verify

Create bounded authority.

Successful recovery evidence is independently verified and bound to the exact action, state, resources, and expiry.

04 Enforce

Execute once, or refuse.

The protected resource rechecks live state, executes the stored action, and atomically consumes the permit.

Model confidence is provenance.

Recovery evidence is authority.

A permit is limited to the rehearsed action and current state. It expires, is used once, and is refused when its proof no longer applies.

03 · Evidence through correction

RF was changed by what it found.

RF keeps the record of unsafe paths, refusals, corrections, and reruns. Successful tests matter, but the sequence of discovery and correction is the stronger maturity signal.

PRODUCT · POSTGRESQL Release evidence

A working enforcement wedge

PINCR is an installable PostgreSQL control with certified release evidence and a verified cold operator path.

PostgreSQL is the first enforcement domain.
ASSURANCE · SHARED CORE Cross-domain evidence

Evidence that travels

The shared Core has been certified across authority models bound to execution, admission, and capabilities.

The witnesses support the protocol thesis; they are not additional products.
CONTROL · REFUSE BY DEFAULT Bounded authority

A deliberate operating model

Recovery evidence governs whether a proposed action receives authority. Refusals and negative controls are part of the evidence surface.

The supported boundary is explicit; broad production certification is not claimed.
ADVERSARIAL EVIDENCE · NOT A DEMO SCRIPT

The evidence includes refusal cases and negative controls, so a system that merely refuses every request does not pass.

INDEPENDENT PRODUCT EVIDENCE · NOT TRACTION

Independent maintenance work confirmed genuine historical migration defects surfaced during evaluation. It is product evidence, not a customer relationship or endorsement.

Qualification history

Maturity is what the system has survived.

RF’s qualification history includes more than successful runs. Unsafe paths, failed qualification runs, and refusal cases were retained as evidence and used to change the architecture.

01 / FOUNDATION

A permit has limits

RF binds every permit to one action, the current state, an expiry time, and one execution at the protected resource.

02 / ADVERSARIAL TESTS

Unsafe paths are part of the test

Registered attacks, negative controls, and refusal cases show that RF does more than approve successful cases.

03 / CORRECTION

Evidence changes the system

Qualification exposed unsafe designs and defects. The fixes changed the architecture and preserved the claim boundary.

04 / WITNESSES

The core works in three settings

PostgreSQL, Kubernetes, and Linux test the core across execution, admission, and capability authority.

05 / DISTRIBUTED SYSTEMS

Failures stay in the record

Recovery and HA work preserved successful outcomes and permanent evidence from runs that failed.

06 / ENDURANCE

Recovery holds over time

The three hour AWS campaign recorded 2,338 passing recovery pairs. It used six fresh tables, each for 30 minutes.

Read the AWS campaign record →

Campaign evidence does not establish qualification for loss of a leader or quorum, external production acceptance, or universal recoverability.

THE POINT IS NOT “NO FAILURES.” THE POINT IS THAT FAILURES CHANGED THE SYSTEM.

04 · Operator journey

Installable infrastructure, not a concept diagram.

Verified on fresh containers. Start with a bounded staging database, never production first.

01
Diagnose rf doctor

Checks prerequisites without changing the database. RF prints the exact grants it needs.

02
Initialize rf init

Connect staging and its disposable shadow after prerequisites pass.

03
Match state rf shadow reload

Rebuild the shadow from staging and prove that the two match.

04
Rehearse rf guard --issue-only

Run forward and rollback on the shadow; issue a permit or record a refusal.

05
Apply once rf apply

Recheck staging, execute the exact stored SQL, and consume the permit.

Between diagnosis and initialization, the operator applies the prerequisite grants printed by rf doctor. Refusals are recorded evidence, not failed demos.

05 · Security boundary

Credibility begins where the claim stops.

RF demonstrates a recovery property for a governed action. It does not claim universal reversibility, desirability, or broad production validation.

ESTABLISHED
  • PostgreSQL is the first shipped enforcement wedge.
  • An agent can propose a production change without holding production credentials.
  • Authority can be bound to the exact action, current state, expiration, and a single execution.
  • Refusals remain part of the durable evidence surface.
NOT ESTABLISHED
  • No external production deployment or acceptance in staging operated by a partner yet.
  • External effects such as HTTP, queues, files, and email remain outside the PostgreSQL recovery boundary.
  • Demonstrated recovery does not prove that every proposed change is desirable.
  • Broad production certification and universal reversibility are not claimed.

06 · Current stage

From qualification into evaluation.

PINCR is opening a small number of design partner evaluations for teams operating consequential PostgreSQL infrastructure and production automation. The purpose is evidence from staging controlled by the customer before any bounded production pilot.

No formal design partners or external production deployments are established yet.

Enter PINCR

Three direct paths.

Evaluate RF against your own staging boundary, open a design partner or strategic conversation, or report a security concern directly to the team responsible.

01 · EVALUATE RF Run a staging evaluation 02 · TALK TO PINCR Design partners and strategic conversations 03 · SECURITY Responsible disclosure