Method, publications and research
The Four Gaps, Field Kit, 244-control register, Harbor Desk worked example, Failure Ledger and public Vigilance reports.
Inspect the Field Kit →The PRAE approach / In development
Security intent,
made testable.
Turn what a system must allow and refuse into explicit obligations. Keep the evidence connected as the system changes.
This is our proposed architecture. The integrated compiler and verification loop have not yet been implemented and benchmarked as a complete product.
Begin with the boundary.
“Build a document export” is a feature request. The security requirement also needs to say whose documents, under which authority, through which paths.
- 01
Specify
The Boundary Contract Compiler would translate application context into explicit allowed, denied and unverified requirements.
- 02
Test
A separate verification harness would execute supported positive and negative assertions against those approved requirements.
- 03
Substantiate
The Evidence Continuity Engine would retain the build, deployed conditions, test results and responsible owner with each conclusion.
- 04
Revisit
Changes to code, permissions, tools or relevant threats would identify affected conclusions for targeted reassessment.
A model may draft a contract. The responsible owner must approve its intent. The agent that writes the code cannot simply declare its own implementation verified.
Contract design / Illustrative
One feature.
Every relevant path.
Access rules must hold across the API, background worker, object storage and download.
A revoked member should not retain access because a queued export or an old link escaped the original check. The contract records those obligations before implementation.
This example is a proposed format. It is not generated output, a supported schema or a runnable test suite.
PRAE / Proposed boundary contract
boundary: customer_document_export
intent:
allow: member exports own organization’s documents
deny: member exports another organization’s documents
execution_paths:
- api
- background_worker
- object_storage
- download
required_verification:
- authorized_export_succeeds
- cross_tenant_export_denied
- revoked_member_denied_after_queue
- old_download_link_denied
evidence:
- source_commit
- test_environment
- deployed_configuration
- observed_results
invalidate_on:
- authorization_policy_change
- worker_implementation_change
- storage_permission_change
- new_export_pathCurrent status
The foundation is here.
The integrated engine is the work ahead.
Scoped checks and recorded results
Ship Kit alpha checks four narrow assertions using broken and corrected synthetic fixtures. These passes do not establish whole controls.
Read the before and after reports →Local assessment and evidence
The private platform pilot implements scoped examination, finding history, remediation verification and reporting. Public sales and distribution are not open.
Review the supported scope →Contracts and continuous verification
The integrated Boundary Contract Compiler, independent business-boundary tests, dependency-aware evidence and targeted reassessment require implementation and engineering validation.
Discuss the development direction →The work that can compound
Learn from a failure.
Keep the test.
The intended commercial asset is a maintained library of executable requirements, realistic failure scenarios, independently checked corrections and rules for when to test again.
Research informs a failure model. The model informs a contract and test fixture. A verified correction becomes a pattern that can be checked again in future work.
We must build that corpus from permitted research, our own synthetic fixtures and authorized contributions. Customer-controlled software does not give us access to private repositories or assessment outcomes.
Public principles. Separate implementation.
The free Four Gaps guide explains the method under its published license. Commercial publications and future implementation software have their own terms. The Field Kit does not include a future software entitlement.
What we still need to demonstrate
Better outcomes.
Measured independently.
These ideas have precedents in software assurance. A proprietary format alone is not a demonstrated advantage.
The proposed benchmark gives PRAE and an established alternative the same imperfect AI-built application, with an independent developer operating each.
- Relevant requirements established before changes
- Meaningful failures found without unsupported conclusions
- Usable corrections and independent negative tests
- Evidence tied to the actual release
- Correct reassessment after conditions change
Measure human time, false positives, missed failures, successful corrections and recurring effort. Results are not yet available.
Discuss a pilot or evaluation