Technical Validation Laboratory
We test our own claims, and publish how.
The Technical Validation Laboratory is not a separate building or an external body. It is LaunchLane's internal test protocol: named, repeatable procedures run against the live product, with pass criteria fixed before the run and results recorded whether they pass or fail.
Protocol
LL-IVT-001
Result
8 of 8 criteria passed
Run by
Omotoke Ogunfuye, founder and technical author
Objective
Show that LaunchLane keeps strategic state across dependent modules, and that a founder's decisions and version changes actually change later AI-assisted recommendations. Run on the fictional test venture "Kerbline Technologies", created through the normal sign-up flow on a clean database.
Pass criteria and observed results
| Step | Expected | Observed | Evidence | Result |
|---|---|---|---|---|
| A · Confirm Positioning | The confirmed version becomes the upstream source. | Positioning confirmed and pinned as the released version. | UI + database | Pass |
| B · Generate Messaging | Messaging records the Positioning version it used. | Recommendations labelled "built from positioning v2". | UI + database | Pass |
| C · Reject a recommendation | The rejection persists. | Stored with status 'rejected' and a fingerprint; shown in Decision memory. | UI + database | Pass |
| D · Regenerate towards the rejected idea | The same or near-duplicate concept is excluded. | "1 suggestion blocked by your past rejections" shown; blocked item never saved. | UI + source code | Pass |
| E · Edit confirmed Positioning | The previous confirmation becomes stale. | Module returned to draft with a reconfirm notice; old version kept in history. | UI + database | Pass |
| F · Attempt downstream use | The system identifies stale upstream state. | Messaging refused: "Confirm the upstream work first." | UI | Pass |
| G · Reconfirm Positioning | The new version becomes the confirmed source. | Version 3 released downstream. | UI + database | Pass |
| H · Regenerate Messaging | Messaging records the new version. | New output labelled v3; earlier output stays labelled v2. | UI + database | Pass |
Faults found and fixed during the run
- A new founder's venture was not saved to the database after setup.
- Access rules prevented the very first venture from being created.
- Four module pages broke a React rule that could crash on load.
Limitations
- Internal test, not independently audited or certified.
- Version numbers start at v1 on first save, so the first confirmed release was v2.
- Rejection matching uses exact fingerprints and word overlap; a reworded idea can still get through.
- One venture, one run. It shows the mechanism works, not how founders respond to it.