A verifier answers a question that matters.
A morning report should exist. A customer should be able to log in. A generated CSV should contain the expected records. An email should arrive with the right attachment. A database and a delivered file should agree.
A BRS verifier turns that knowledge into a small program that produces structured evidence. The important part is knowing what must be true before you are willing to say, “this capability works.”
Don't start with a blank file.
BRS-Core includes a canonical skeleton plus multiple working verifiers that run against the live W3Patterns Reference Application. Run them immediately. Read the code. Watch them exercise real capabilities. Modify them. Use them as patterns for your own business.
Working examples include browser login, API verification, database reads, SFTP-delivered business files, and a multi-system daily claims report.
If you want to try the verifier model before buying Core, the free Verifier Starter Kit includes a real independently executable verifier and the canonical skeleton.
The contract is what makes the pieces fit.
Every verifier that BRS-Core runs must follow the BRS verifier contract. This is not merely a style convention. It is the integration boundary that lets Core discover the verifier, schedule it, enforce its timeout, record its result, and expose predictable output to BRS-Server and the monitoring tools connected to it.
Follow the contract and your verification logic stays portable, understandable, and sane.
module.exports = {
id: 'daily_orders_file',
label: 'Daily Orders File',
schedule: {
interval: 300,
timeout: 30
},
async verify() {
return {
summary: 'Daily orders file verification completed successfully.',
steps: [
{
name: 'verify_file_exists',
label: 'Verify File Exists',
success: 1,
durationSeconds: 0.018,
message: 'daily-orders.csv exists and is readable.',
checkedAt: new Date().toISOString()
}
]
};
}
};
id — Stable, unique machine-readable identifier.label — Human-readable verifier name.schedule.interval — How often Core runs it, in seconds.schedule.timeout — Maximum run time before Core records a timeout.verify() — Your asynchronous verification logic.summary — Concise human-readable overall result.steps — Evidence: name, label, success, duration, message, and checked-at timestamp.observations — Optional measured values a verifier also needs to report.A verifier does not need BRS-Core to execute.
Independent execution is a core design rule. That makes a verifier easy to build, troubleshoot, test, and understand before it ever becomes a scheduled job.
$ node daily-orders-file.js
A successful verifier returns structured evidence:
{
"summary": "Daily orders file verification completed successfully.",
"steps": [
{
"name": "verify_file_exists",
"label": "Verify File Exists",
"success": 1,
"durationSeconds": 0.018,
"message": "daily-orders.csv exists and is readable.",
"checkedAt": "2026-08-15T21:30:00.000Z"
}
]
}
The same verifier can then run unchanged under BRS-Core. Core supplies the orchestration around it; the verifier continues to own the business logic.
Make the business condition false and the result stays understandable.
If the expected file disappears, the failed step records what was checked, whether it succeeded, how long it took, when it was checked, and a useful message.
{
"summary": "Daily orders file verification failed.",
"steps": [
{
"name": "verify_file_exists",
"label": "Verify File Exists",
"success": 0,
"durationSeconds": 0.018,
"message": "daily-orders.csv was not found.",
"checkedAt": "2026-08-15T21:30:00.000Z"
}
]
}
This consistent shape lets dashboards and alerts identify the capability and the exact step that failed.
You write the proof. BRS-Core operates it.
Your verifier owns
- Dependencies
- Configuration
- Verification logic
- Definition of success
- Human-readable evidence
BRS-Core owns
- Verifier discovery
- Scheduling
- Timeout enforcement
- Latest result recording
- Prometheus metrics and operational output
That boundary is deliberate. BRS-Core does not need to understand your business. Your verifier does. Core needs the verifier to honor the contract.
The included examples verify a live application.
These are not placeholder “hello world” scripts. BRS-Core ships with working examples designed to exercise the W3Patterns live Reference Application and demonstrate different verification patterns.
Client Login
Browser automation authenticates and verifies the logged-in experience end to end.
Public API
Calls a live API and validates the response and expected business content.
Database Read
Uses restricted demo access to verify authoritative application data.
SFTP Business File
Confirms an expected business file exists, is readable, and contains useful content.
Then see composition.
The Daily Claims Report example crosses application state, database data, an SFTP-delivered CSV, file freshness, row counts, totals, and cross-system agreement to answer one business question: did today's claims-reporting process actually work?
Bring the business knowledge. Let AI help with the implementation.
You know what “working” means in your environment. Modern AI coding assistants can help turn that knowledge into JavaScript while the BRS verifier contract constrains the shape of the result.
Start with an included verifier or the skeleton. Give your coding assistant the contract. Describe exactly what must be proven. Then review the code, run it directly, and refine it until it proves what matters.
A useful prompt might look like this:
Using this BRS verifier skeleton and preserving its contract, create a verifier that connects to our SFTP server, confirms daily-orders.csv exists, verifies that it was modified today, and fails if the file is empty. Keep each business check as a separate verification step.
You are not asking AI to invent what your business needs. You provide the domain knowledge and acceptance criteria. AI can help with the implementation mechanics.
Build it once. Operate it consistently.
When your verifier follows the contract, the same independently executable module can run under BRS-Core, become part of BRS-Server, and produce predictable data for Prometheus, Grafana, Alertmanager, or other systems consuming Core's outputs.
This is why the contract is required. Without a stable boundary, every custom verification becomes a custom integration. With the boundary, your business-specific code plugs into a common operating model.
Replace our business with yours.
A customer login. A nightly reconciliation. A report delivery. A generated file. An API-backed process. A document emailed to a customer. The contract stays the same; the business evidence changes.
Every verifier remains independently executable. BRS-Core operates approved verifiers continuously as part of 24/7 business capability monitoring.