- AI agents materially create or change production software.
- A failure could affect money, sensitive data, operations, regulatory evidence, or an important decision.
- Tests pass, but the team cannot show which production behavior those tests actually prove.
- Leaders need a defensible record of what is proven, what remains assumed, and what must change.
Quant Assurance Framework (QAF)
Your AI agents can build faster than you can verify.
QAF gives AI-built software a definition of done that requires proof. It adds clear rules, required checkpoints, and a record of the evidence inside the repository. Passing tests is not enough. The deployed software must also behave as intended.
For teams shipping AI-built quantitative, financial, and other high-consequence software.
False confidence compounds
Three ways a clean result can still be wrong.
AI can produce convincing code, tests, documentation, and results that all agree. Agreement is not proof when the same system created every answer.
- 01 / SAME AUTHOR
One AI system writes the feature, the tests, the documentation, and the claim that the work is finished.
Every output can repeat the same misunderstanding. Internal agreement is not independent confirmation.
- 02 / REAL SYSTEM SKIPPED
Tests pass without testing what customers actually use.
A test may replace the database, payment service, AI model, or deployment setup with a simplified stand-in. The test passes, but the real path was never exercised.
- 03 / WRONG MEANING
Software runs successfully while producing the wrong meaning.
A forecast, risk score, system state, or financial metric can return a valid-looking result that no longer means what the user thinks it means.
How QAF works
QAF makes proof part of the development workflow.
Each material change begins with an expected behavior and ends with evidence from the deployed system. QAF records the result and strengthens the controls when failures escape.
- 01
Define the expected behavior.
State what the software must do, who owns that behavior, and what evidence will prove it.
- 02
Require evidence during development.
Install repository controls that stop work from being accepted when required evidence is missing, stale, or disconnected from the change.
- 03
Verify the deployed system.
Exercise the real production path and confirm the result where users or downstream systems actually depend on it.
- 04
Record the decision.
Accept or reject the work with a durable record of the evidence. When a failure escapes, update the controls so the same gap is checked next time.
What QAF installs
An enforceable assurance system inside your repository.
- 01
Rules for AI-assisted work
Define how material changes must be designed, tested, reviewed, and supported by evidence.
- 02
Risk and ownership map
Connect critical behavior to its owner, required controls, and authoritative evidence.
- 03
Repository checkpoints
Reject risky work when required evidence is missing, stale, or tied to the wrong change.
- 04
Production verification
Confirm critical behavior through the real path used by people or downstream systems.
- 05
Assurance record
Preserve requirements, evidence, decisions, and incidents for each governed result.
Fit filter
Use QAF where “probably correct” is not enough.
- You want a badge, broad certification, or a guarantee that the entire system is correct.
- You need a quick code review or estimate without a defined system, scope, and decision owner.
- The relevant behavior, production version, and responsible owner cannot be identified.
- Failure carries little consequence and standard engineering review is proportionate to the risk.
How to engage
How a QAF engagement works.
Assessment and implementation form the required engagement. Each is separately priced and authorized. Managed Assurance is an optional continuation, arranged separately. The assessment selects the first bounded implementation; it does not authorize repository or production changes by itself.
- 01 / ENTRY
Apply and qualify
Tell us what the system does, what depends on it, and why proof matters. We review fit before requesting technical detail or access.
- 02 / ASSESS
QAF Assessment
A paid, bounded diagnostic confirms the important behavior, the owner, the current proof, and the first implementation to authorize.
- 03 / IMPLEMENT
QAF Implementation
Under separate authorization, license and install QAF, configure checkpoints, connect agent workflows and CI, and verify the production paths that matter.
- 04 / OPTIONAL
Managed Assurance — by arrangement
Keep the controls current, review failed or escalated work, update QAF after incidents, and maintain production evidence.
Explicit boundaries
QAF proves defined claims.
It does not replace accountable judgment.
- No blanket assurance
QAF is not a certification. It does not guarantee that an entire system is correct.
- No replacement for experts
QAF does not replace security testing, legal or compliance advice, domain experts, or accountable owners.
- Domain ownership stays with you
QAF verifies approved behavior. It does not invent strategies, business rules, or production decisions.
FAQ
Before you apply.
Is QAF software or a service?
QAF is licensed software installed into a repository and its development workflow. The QAF program also includes a paid assessment method, an implementation process, and managed operation by arrangement.
Why does an engagement start with an assessment?
The assessment identifies which behavior matters, where current tests or evidence can give false confidence, and which QAF checkpoints and integrations the repository actually needs. It selects the first bounded implementation; it does not authorize repository or production changes by itself.
Is the assessment a free code review?
No. It is a paid, bounded diagnostic. It identifies who or what owns the behavior, tests the strength of the current evidence, identifies ways tests can pass while the product remains wrong, and produces a prioritized QAF implementation scope.
Do you need write access to our repositories?
No. Assessment work begins with the least access needed, normally read-only. Credentials, source code, datasets, and repository invitations should not be sent through this form.
Does QAF certify our software?
No. QAF can issue a passing verdict only when the configured rules and evidence requirements pass. That verdict is limited to those requirements and evidence. It is not certification, a legal or compliance opinion, or a guarantee that all software is correct.
Can BlackArbs implement QAF after the assessment?
Potentially. Implementation is separately scoped and authorized after the assessment. It can include the licensed QAF package, repository rules and checkpoints, agent workflows, CI checks, production verification, operator training, and handoff.
What happens after I apply?
We review the application by hand. If QAF appears to fit, we send the next qualification step. Before requesting repository access, we define the proposed scope, deliverables, timeline, which evidence may be examined, and price.
How quickly will I hear back?
Expect a response within two business days. There is no automatic acceptance, rejection, or scheduling.
QAF application
Show us the consequence, not your secrets.
Describe the system, what depends on it, and why false confidence would matter. We review every application before requesting technical detail or access.
Do not send credentials, source code, datasets, or repository access.
Describe the system and consequence at a high level. Access is discussed only after qualification.