Source
What system state, authority, document, code path, data, or configuration supports the work?
Proof model
Source → Test → Review → Decision
The proof model connects a known system state to representative evidence, named human review, and an explicit decision without pretending that one artifact proves everything.
Proof disciplineConnect evidence to a decision
- Purpose
- Link source state, representative tests, named review, and an explicit decision condition.
- Boundary
- Evidence supports a decision; it does not create certification, assurance, or certainty.
Evidence sequence
Four links from system state to action
Test
Which representative, negative, edge, access, refusal, or parity cases were examined?
Review
Who reviewed the result, what was disputed, and what remains unknown?
Decision
What proceeds, narrows, remediates, rolls back, or stops—and under which conditions?
What a decision package contains
- Defined system and decision boundary
- Source and configuration inventory
- Representative test or review cases
- Observed results and failure taxonomy
- Named human review and disagreement
- Unknown, disputed, and excluded conditions
- Proceed, narrow, remediate, rollback, or stop criteria
- Retained artifacts and next review date
What proof does not mean
- A universal guarantee of accuracy, security, compliance, or business outcome
- A customer case study when the record is a demonstration or key-personnel example
- A certification, attestation, audit, penetration test, or legal opinion
- Permission for AI to act without explicit authority
- Evidence that applies beyond the named system state and case set
Evidence taxonomy
Read the classification before evaluating the claim
| Evidence type | Definition | Public boundary |
|---|---|---|
| Verified client case study | Client work approved for public attribution and factual outcome reporting. | Names, outcomes, and metrics appear only with verified approval. |
| Approved anonymized case study | Client work approved for public discussion without identifying the client. | Context is generalized and unsupported metrics are omitted. |
| Key-personnel past performance | Relevant work performed by the principal before or outside the current entity. | It is not presented as LongTermCapabilities corporate or federal-prime past performance. |
| Corporate past performance | Verified work contracted and delivered by the current business entity. | Published only when contract and disclosure authority are verified. |
| Method demonstration | A controlled example showing how a method, interface, or evidence pattern works. | It is not a customer outcome and may use synthetic data. |
| Technical reference architecture | A public architecture pattern intended to support technical review and discussion. | It is not proof that a specific client system is secure or production-ready. |
| Public R&D project | A public research or experimental system used to explore methods and constraints. | Research behavior is not represented as commercial deployment performance. |
| Publication or research note | Original technical analysis supported by named sources and limitations. | It is informative, not legal, audit, or certification advice. |
Representative records
Three examples with different evidence boundaries
Key-personnel past performancePublicly documented key-personnel background
Enterprise Microsoft systems delivery across rule-heavy domains
Mike Kappel has more than two decades of public professional history delivering and modernizing Microsoft-based enterprise systems across commercial and public-sector contexts.
Boundary: This is key-personnel experience, not LongTermCapabilities corporate government past performance. It does not identify confidential clients or claim unverified metrics.
Open evidence recordMethod demonstrationPublic method demonstration
AI evaluation and blocked-action program
An AI reviewer, copilot, or agent produces useful demonstrations, but acceptable failure, human review, and prohibited downstream actions remain undefined.
Boundary: This is an evaluation pattern, not a formal audit, safety certification, or guarantee that a system will be error-free.
Open evidence recordPublic R&D projectPublicly inspectable research artifacts
Governed handoff and machine-readable evidence research
Long-running software and AI-assisted work requires durable handoff records, source boundaries, review status, and public/private separation.
Boundary: Public R&D is not a client engagement, certification, or proof of suitability for a specific regulated environment.
Open evidence recordNext action
Bring the system, the trigger, and what cannot fail.
Start with public-safe context. Sensitive evidence moves only after fit, responsibility, scope, and an approved channel are clear.
Prefer a direct conversation? Call 1 (464) 274-1476