Research & Development
- Implemented prototype foundations
- The published reference experiment demonstrates candidate cryptographic source observations, canonical evidence commitments and layer-specific receipt checks within a controlled fixture. A separate engineering prototype represents evidence, claims and derivation-rule provenance and implements graph-object persistence. These components do not establish automatic dependency inference or validated migration decisions.
- Experimental research
- R2PQ is investigating how to derive useful, evidence-bounded cryptographic dependency and migration conclusions when information is incomplete, stale, correlated or contradictory. The research concerns when a conclusion is justified, when it should remain unresolved, and whether useful recommendations can be retained without unsupported certainty.
- Longer-term direction
- The broader direction is cryptographic resilience across discovery, inventory, evidence, dependency understanding, risk, migration, verification and crypto-agility. These are research and engineering objectives, not a completed feature set.
Inspect the controlled reference experiment and its limitations.
03 / WHAT A DEFENSIBLE ANSWER LOOKS LIKE
A claim is only as useful
as its boundaries.
Evidence, interpretation and review stay distinguishable. This fictional example shows how a broad claim becomes a precise customer response.
For implemented evidence, inspect the controlled reference experiment or use the receipt verifier. The reference publishes its expected observations, one residual false positive, unsupported cases and unavailable trust layers.
ILLUSTRATIVE FINDING · CR-014API SERVICE / RELEASE 2.4
CLAIM UNDER REVIEW
“All application traffic uses approved cryptography.”
!Partially supported — the broad claim is not established for the stated scope
01
Source / observation
The supplied outbound-client configuration sets a minimum TLS version of 1.2.
Source: client-config.yml · lines 18–21 · release 2.4 snapshot
Inspect the illustrative source
# Illustrative configuration only
outbound_client:
tls:
minimum_version: "1.2"
This record describes supplied configuration, not a runtime observation.
02
Deterministic check
The field exists and its literal value equals 1.2.
Example check CFG-01 v1 · supplied file only · result: passed
A passed field check does not establish negotiated protocols, cipher suites or policy approval.
03
Analyst / AI interpretation
The configuration supports a narrower statement about this client. It does not substantiate “all traffic” or “approved cryptography.”
Origin: illustrative analyst interpretation · AI contribution: none in this example
04
Unknown / not evaluated
Deployment overrides, other traffic paths, negotiated cipher suites and the customer’s approval criteria were not evaluated.
Next evidence: deployed configuration, relevant runtime records and the applicable policy.
05
Human review
Disposition: narrow the response and request additional evidence before making the broader claim.
Illustrative reviewer: assessment lead · review scope: this finding
06
Verification result
The example field check passed. The broad claim remains unverified.
The R2PQ receipt checks described here concern committed payload hashes. They do not validate this fictional configuration check or runtime security.
THE SCOPED RESPONSE
“The supplied release configuration specifies a minimum of TLS 1.2 for this outbound client. Deployed behavior, other traffic paths and compliance with your approval criteria have not been established.”
RECOMMENDED NEXT ACTION
Obtain the deployed configuration for this release and the customer’s stated approval criteria, then re-state the claim at the scope that evidence supports. Until then, the narrower response above is the defensible answer.
05 / HOW CONCLUSIONS ARE REVIEWED
Review expectations
and evidence boundaries.
This is the proposed review structure for an engagement. Section 03 illustrates it; the current receipt does not authenticate reviewer identity or operator provenance.
- Source artifact
- Observation
- Deterministic check
- Interpretation
- Human review
- Unknown / limitation
- Recommended action
Who reviews
Founder & Assessment Lead
Assessments are reviewed by the founder and assessment lead. Material conclusions are based on documented evidence, defined checks and explicit scope. Where specialist validation is required beyond the engagement’s evidence or competence, the conclusion remains unresolved rather than being inferred.
This is founder-led technical review. It is not independent assurance, accredited review, certification, a third-party audit or a licensed cryptographic assessment.
What each stage can establish
- Automated detection
- Produces candidate observations. A candidate is not a finding, and absence of a candidate is not absence of the thing.
- Deterministic checks
- Establish only the defined technical condition, against the supplied input, at the recorded time. Method, version, scope and limitations are recorded with the result.
- AI assistance
- May help interpret or draft. It is not evidence, it is identified where it is used, and it does not decide anything material.
- Human review
- The founder and assessment lead decide whether a conclusion is supported. Review is not the same as approval, and approval is not the same as technical truth.
- Specialist validation
- Where the engagement’s evidence or competence is insufficient, the conclusion stays unresolved and the specialist input required is named. It is not inferred.
- Unsupported conclusions
- Remain inconclusive or not evaluated, and are reported that way rather than being resolved by inference.
- Scope and exclusions
- Are part of the deliverable, not a preamble to it. A conclusion travels with the boundary it was established within.
How a conclusion is dispositioned
- Supported
- The evidence establishes the claim within the stated scope.
- Partially supported
- Part of the claim is established; the remainder is not.
- Contradicted
- The evidence is inconsistent with the claim as stated.
- Inconclusive
- The evidence does not settle the question in either direction.
- Not evaluated
- Outside the agreed scope, or no evidence was collected for it.
- Needs further evidence
- A specific additional artifact would settle it, and that artifact is named.
“Verified” is used only where a named verification procedure actually passed, inside its own scope and time. “Secure”, “compliant” and “PQC ready” are not used as states of a system. This site claims no accreditation, no certification authority and no independent assurance standing.
07 / INFORMATION HANDLING
Send the question first.
Not the evidence.
These are the handling expectations for an engagement. Where an arrangement is not yet operationally established, it is stated below as a requirement to be agreed — not as a control that already exists.
The first inquiry carries no evidence
Name, company, business email, the type of request you received, and a deadline. Nothing technical is needed to determine fit.
Do not send secrets through this path
Source code, credentials, private keys, cryptographic key material, internal configuration, customer-confidential material and regulated data do not belong in a public inquiry form or in an unplanned email.
Evidence follows scope, not the reverse
Assessment material is collected only after scope, exclusions and a transfer method are agreed. That is step 04 of the sequence above.
PROPOSED REQUIREMENT Transfer method agreed in writing
No transfer mechanism is offered, operated or implied by this site today. One must be agreed before any evidence moves.
PROPOSED REQUIREMENT Local or customer-controlled analysis preferred
Where feasible, analysis should run under your control rather than requiring material to leave your environment. Feasibility depends on the request and is settled at step 03.
PROPOSED REQUIREMENT Retention and deletion agreed before acceptance
No retention period, deletion process or storage arrangement is currently established. These must be agreed before sensitive evidence is accepted.
What this site does with your information
The checked-in inquiry script prepares text locally and opens a mailto link; it has no form-submission endpoint, analytics call or persistent application storage. Hosting requests, browser behavior and the mail provider are separate from that code. This is not a claim that hosting has no logs or injected services.
Email is the temporary inquiry mechanism while a dedicated intake is built. Once you email us, your message sits in an ordinary mailbox. We claim no encryption at rest, no deletion timescale, no secure vault and no certification of any kind. Retention and deletion for sensitive material are agreed before such material is accepted — which is why the initial inquiry carries none.
The section above states engagement expectations, not a legal privacy programme. This site is published for qualification only. A fuller privacy notice and written engagement terms are required before any paid engagement or broader intake, and sensitive technical evidence is not accepted through this public path.