Three market-entry products · One authority core

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 available for PostgreSQL, Kubernetes, and Linux. Each product enforces at the boundary where its consequential action becomes real.

See the mechanism Choose a product evaluation

MARKET ENTRY · THREE PRODUCTS

PostgreSQL execution · Kubernetes admission · Linux capability

RF / AUTHORITY BOUNDARY DETERMINISTIC OUTCOME

AI proposes → RF proves → Boundary decides

01 proposal.bound PASS

02 recovery.proven PASS

03 live.state MATCH

04 authority.single_use READY

DECISION Authorize exact stored action once PERMIT

AGENT CREDENTIAL NONE UNSAFE AUTHORITY REFUSED

AI proposes

RF proves

Protected resource decides

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.

01 Agent or automation
Proposes a consequential production action.
02 Identity and policy
Establish who or what may ask.
03 PINCR
Establishes that this exact action can recover from current state.
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 · Market-entry products

One control primitive. Three products.

The shared protocol binds authority to recovery evidence. Each product adapts that protocol to the trust boundary, state model, and enforcement point of its domain.

PRODUCT 01 · POSTGRESQL Execution authority

Govern database change.

RF rehearses the exact forward and recovery SQL on a disposable shadow, binds a permit to live database state, then executes and consumes it at the database boundary.

Market-entry product · transactional change control

PRODUCT 02 · KUBERNETES Admission authority

Govern cluster admission.

RF evaluates a consequential API mutation against live cluster state and recovery evidence before the validating admission boundary allows the object to persist.

Market-entry product · Kubernetes change control

PRODUCT 03 · LINUX Capability authority

Govern privileged host action.

RF issues narrowly scoped, short-lived authority for an exact Linux operation, rechecks host state at execution, and consumes the capability once.

Market-entry product · host capability control

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 / PRODUCTS

One core, three authority boundaries

PostgreSQL governs execution, Kubernetes governs admission, and Linux governs capability. Each is a market-entry product, not a witness standing in for another.

05 / DISTRIBUTED SYSTEMS

Four failure modes, no second writer

On independent AWS hosts RF fenced the former primary, replaced a permanently lost worker only after fencing its old owner, and under quorum loss reported uncertainty rather than guessing an outcome.

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 →

All four high-availability cells passed in one fresh ordered campaign on independent AWS hosts: leader-host loss with fencing and successor operation, ambiguous remote outcomes resolved by readback rather than a blind retry, permanent worker replacement admitted only after old-owner fencing, and authority-store quorum loss in which RF reported the interrupted action as unestablished, reconciled read-only without ever replaying it, and recovered under a freshly qualified permit. The campaign is bounded: it does not establish independent restoration of the preserved initial state, production-wide availability, or a repeatability rate. No external production acceptance, and no claim of universal recoverability.

04 · Native enforcement

Three products, enforced where consequences become real.

The proposal and proof protocol is shared. Observation, recovery, execution, and consumption stay native to each domain.

PostgreSQL EXECUTION

The database rechecks current state, executes the exact stored SQL, and consumes authority transactionally.

Kubernetes ADMISSION

The API server reaches the RF webhook before persistence; stale evidence or object drift causes refusal.

Linux CAPABILITY

The host accepts only the scoped operation and state named by a current, single-use capability.

Uncertain outcome RECONCILE

RF reads production state to establish what happened. It never converts ambiguity into permission for blind replay.

Changed reality REQUALIFY

When protected state or recovery assumptions change, old authority stops applying and fresh evidence is required.

The three products do not pretend their recovery mechanics are identical. They share the authority invariant: exact action, current state, bounded lifetime, one consumption, explicit refusal, and read-only reconciliation when the outcome is unknown.

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, Kubernetes, and Linux are three market-entry products.
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.
Effects outside each product’s declared boundary remain outside RF; HTTP, queues, files, and email are not implicitly covered.
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 across PostgreSQL, Kubernetes, and Linux. Each evaluation starts at one bounded staging authority boundary before any production pilot.

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

Enter PINCR

Three direct paths.

Choose a PostgreSQL, Kubernetes, or Linux staging boundary, open a design partner or strategic conversation, or report a security concern directly to the team responsible.

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