Define the app's job

Useful prototypes attract requests. Vendor Review could soon negotiate contracts, provision accounts, monitor renewals, or block purchases. None of those requests helps establish whether the current application is ready for production. Negotiating contracts would be quite a promotion for a four-field form. First, prove the form works.

Decide what belongs in this release

Before writing a contract, classify these requests as now, later, or not this application. Make the decisions before opening the answer.

Open the Application job section of docs/readiness.md. It records the decisions you just made without asking you to start another document.

Purpose

Use one sentence:

Help a small Procurement and Security review group identify incomplete or higher-risk software requests and route them to the right human.

Avoid claims such as “automate vendor approval.” The application does not have that authority.

Business outcome

Name the pain in the current process before naming a product or feature. For Vendor Review, incomplete requests force Procurement and Security to gather missing context before they can make a decision.

Record one baseline and one target:

Current process:
Business owner:
Baseline measure:
Target measure:
Review date:

A useful target might reduce the percentage of requests returned for missing information or shorten the time from a complete submission to a reviewer decision. The measure should describe the business process, not page views, model calls, or the number of features shipped.

Include in this release

• Collect a consistent vendor request
• Identify missing information
• Apply written cost and data-handling policy
• Suggest a risk classification
• Route requests that require review
• Preserve the assessment and human decision

Leave out of this release

• Purchasing software
• Signing contracts
• Provisioning employee accounts
• Making a final security or legal determination
• Replacing the source-of-truth procurement system

Choose the first users and owners

Name a small test group and assign roles, even if one person fills several during the course:

• Application owner
• Technical owner
• Procurement reviewer
• Security reviewer
• Test group

Evidence

Choose evidence before the dashboard exists:

• Completion rate for submitted requests
• Percentage returned for missing information
• Agreement between routing policy and human reviewers
• Time from submission to decision
• Model failures or invalid outputs
• Cost per assessment

The evidence should be capable of disproving the application’s value. “People liked it” is feedback. It does not prove that the review process improved.

Pressure-test the contract

Ask another person to play a stakeholder and choose one excluded behavior. Give yourself sixty seconds to explain why it is excluded and what evidence would justify reconsidering it. If the answer depends on “we can probably add it,” the decision is not yet clear.

Commit the decision before implementation begins:

git add docs/readiness.md
git commit -m "docs: define the Vendor Review job"

Summary

A production application needs a clear job, a named owner, and evidence that can show whether it works. Define those before the feature requests arrive, or a useful prototype can quietly become an unsupported platform.

Check your work

Give someone only the Application job section. Ask what Vendor Review may decide, what still belongs to a person, and who owns the result. If any answer requires you to explain what the document “really means,” revise the document.