Build a BRS verifier with AI.

Start with the contract. Then describe the business.

First, make the assistant understand the verifier contract.

Attach or paste the canonical skeleton or an included verifier, then use a prompt like this:

Analyze this BRS verifier and the contract it implements.

Before writing or modifying code:
1. Identify the required exported fields.
2. Explain the purpose of id, label, schedule, and verify().
3. Explain the required shape of summary and steps.
4. Explain how success, durationSeconds, message, and checkedAt are used.
5. Identify any optional observations used by this example.
6. Confirm that the verifier must remain independently executable.

Do not redesign the contract or BRS-Core.
Do not write my new verifier yet.
First explain the contract back to me and identify anything you need
from me before implementation.

This separates understanding the integration boundary from generating code. The assistant should work inside the BRS model rather than inventing a new one.

Now provide the knowledge only you have.

Write the requirement the way you would explain it to a knowledgeable coworker. For example:

Business capability: Daily orders file delivery.

What working means:
- A file named daily-orders.csv must exist on our SFTP server.
- It must be today's file.
- It must be readable.
- It must contain a header and at least one data row.
- The business date in the file must be today's business date.

What failure means:
- The file is missing, stale, unreadable, empty, or has the wrong date.

Useful evidence:
- File name
- Modified time
- Row count
- Business date found in the file

Using the BRS contract you just analyzed, propose the verification
steps you would use. Do not write code yet. Tell me what assumptions,
credentials, paths, or configuration values you still need.

This is the critical step. AI should not invent your acceptance criteria. If the proposed steps do not prove the business capability, fix the plan before generating code.

Once the plan is right, ask for the verifier.

Implement the approved verification plan as a BRS verifier.

Requirements:
- Preserve the canonical BRS verifier contract exactly.
- Keep the verifier independently executable.
- Keep configuration and credentials outside the source code.
- Give each meaningful business check its own verification step.
- Return useful human-readable messages for both pass and fail results.
- Record durationSeconds and checkedAt correctly.
- Handle expected errors so the verifier returns understandable evidence.
- Do not modify BRS-Core.
- Do not add unrelated infrastructure monitoring.

After writing the verifier, show me:
1. Any required environment variables or dependencies.
2. How to run it directly from the command line.
3. What a successful result should look like.
4. How to safely force a failure so I can prove the verifier detects it.

Generated code is not verified code.

Read the result and test it against the real requirement. A verifier that executes without errors can still prove the wrong thing.

• Does each step correspond to a real business requirement?
• Can the verifier produce a clear PASS when the capability works?
• Have you deliberately broken the capability and observed a clear FAIL?
• Are secrets and credentials kept outside the source code?
• Are timeouts and schedules appropriate for the dependency being tested?
• Does the verifier return useful evidence without exposing sensitive data?
• Can it run directly without BRS-Core?

The AI-assisted part ends when the verifier is built.

Once the verifier follows the contract and works independently, place it where BRS-Core discovers verifiers. Core can schedule it, enforce its timeout, record the latest result, and expose its operational output.

The verifier understands your business. Core understands how to operate verifiers.

Use this when you are ready to build another verifier.

I am building a verifier for W3Patterns BRS-Core.

First analyze the BRS verifier skeleton/example I provide and preserve
its contract exactly. The verifier must remain independently executable.
Do not modify or redesign BRS-Core.

I will describe a business capability in plain language. Help me turn
that requirement into observable verification steps. Ask only for
technical details that are actually required to implement the checks.
Do not invent business rules or acceptance criteria.

Before writing code:
- Restate what the business capability must prove.
- Propose the verification steps.
- Identify assumptions and required configuration.
- Wait for me to correct the plan if necessary.

After the plan is correct, implement the verifier, explain how to run it
directly, and show me how to test both a successful result and a safe,
deliberate failure.

Know your business well enough to define proof.

You do not need to start by knowing how to automate a browser, query a database, inspect an SFTP file, or call an API. Those are implementation problems an AI coding assistant can help solve.

You do need to know the answer to a more important question: What evidence would convince us that this business capability actually worked?

That answer is where a useful BRS verifier begins.