Bridge 01
Define the AI-native job.
The job is not 'use AI'. The job is to reduce expert drag in the proposal loop while increasing decision quality.
Bridge · Start safely
How should Solar365 start, without overbuying AI?
The bridge is a buyer-safe proof path. It protects Solar365 from vague AI spend and gives Stackmates a concrete outcome demand only after the business case is real.
Bridge 02
Collect 20 recent enquiries.
If there are not enough real commercial or school opportunities to analyse, do not build.
Bridge 03
Reconstruct 5 proposal paths.
Time enquiry -> facts -> draft -> expert review -> sent -> follow-up -> outcome. This is the pain baseline.
Bridge 04
Run one manual cockpit loop.
Use a simple queue, missing-facts list, decision brief, proposal packet, and follow-up tracker before filing Engineering demand.
Bridge 05
Fund Stage 1 only if the proof earns it.
Build only when owner, metric, reuse verdict, tool boundary, and Week 6 kill signal are known.
The ask
Can we take 20 recent enquiries, pick the five highest-value commercial or school opportunities, and rebuild the proposal path end to end so we can see where expert time, follow-up, and value are leaking?
20 enquiry records5 proposal paths1 operator walkthrough and manual cockpit loop14 daysgo/no-go decision for a 90-day proof
Guardrail
Stop if the sample is thin, the operator does not use the cockpit, or Week 6 cannot show at least 30% effort reduction. If it passes, compose existing Stackmates CRM, proposal/quote, RFP, solar helper, and proof primitives instead of rebuilding.