For Users and operators
How to choose an AI-built software listing
Use the demo, source package, delivery artifact, setup facts, inspection notes, and provenance to decide whether a Build is worth cloning, adapting, or taking into a Project Room.
Principles
- A Build listing should show what exists, what Users receive, and what remains open.
- Verification is a report of checks and findings, not a warranty.
- Project Rooms exist for setup, provider configuration, additional checks, and scoped adaptation.
Section 1
Start with what you get
The listing should make the Build understandable before you talk to the Builder.
Check what the Build is
Read the build type, version, delivery artifact, deploy target, setup steps, and known limitations.
- Does the Build match your operating need?
- Can your team run the declared delivery artifact?
- Are the known limitations acceptable for a pilot?
Check required providers
Look for external services, API keys, storage buckets, CRM exports, and data sources that your team must supply.
- Which accounts or credentials are required?
- Which environment variables must be set?
- Which integrations are mocked instead of production-ready?
Check the license
Review commercial use, redistribution limits, access-record type, and support options before treating a Build as reusable software.
Section 2
Read the inspection notes
Inspection notes show what was checked, when it was checked, and which findings were reported.
Look for timestamps
A useful report says scanned at, checked at, and whether the demo was reachable when checked.
Read findings carefully
No findings at scan time means the listed checks did not report findings then. It does not remove the need for User-side review.
Notice checks that have not run
A declared-only listing can still be useful as a reference, but it should not be treated like a listing with a current report.
Section 3
Use Project Rooms for adaptation
When a Build looks promising but needs setup or changes, move the work into a scoped room.
Bring concrete context
Share data sources, provider accounts, team roles, acceptance criteria, deadline, and deployment constraints.
Separate setup from product changes
Provider configuration, environment setup, and additional checks should be scoped separately from new features.
Keep acceptance notes attached
Delivery notes, review comments, and additional work should stay linked to the BuildVersion under discussion.
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.