For Builders
How to list a Build that Users can reuse
Builders should make generated software legible through demos, setup facts, provenance notes, inspection notes, license terms, and support boundaries.
Principles
- Show the Build before packaging the offer.
- Say what was scanned, reported, and checked. Do not overstate verification.
- Keep support and customization attached to the Build instead of turning the Registry into a general services board.
Section 1
Draft the listing
The listing is the product surface for the Build.
Name the Build clearly
Use an operating description, not a tool stack headline. The title should tell a User what job the Build helps with.
Declare runtime requirements
List providers, environment variables, setup steps, deploy targets, and mocked integrations.
- Required API keys and accounts
- Data sources and import formats
- Deploy target and setup sequence
State known limitations
A limitation is useful when it helps a User avoid a mistaken assumption.
Section 2
Write provenance as evidence
Process notes matter when they explain generation, review, and remaining gaps.
Keep source context
Record source tool, model context, generation date, repository commit, and Builder attestation.
Explain human review
Say which areas were reviewed by a person, such as auth flows, role boundaries, calculations, or setup instructions.
Avoid diary copy
The Registry does not need a full build diary. It needs provenance that supports User-side evaluation.
Section 3
Submit reports responsibly
Verification language should be precise and bounded.
Use report language
Use scanned at, checked at, findings, no findings at scan time, and demo reachable when checked.
Do not overstate the result
Avoid claims that imply broad assurance. A report is a record of specific checks.
Keep access terms separate
A Build can be inspectable before it is ready for source access, licensing, or custom setup.
Guides
Product note
These guides are product copy, not legal terms. Source access, refund, access-control, and delivery policies should be separated before production implementation.