Skip to main content

Assessment Input Contract

This is the locked V1 assessment input contract for IED.

Use this as the source of truth for:

  • the canonical public assessment entry route
  • step structure
  • required and optional intake fields
  • serviceability behavior
  • what the assessment intentionally does not capture in V1

Canonical Route​

The canonical V1 assessment entry route is:

  • /start

If /assessment is retained temporarily later, it should redirect to /start.

V1 Assessment Structure​

The V1 assessment is a five-step guided flow:

  1. location
  2. home profile
  3. energy usage
  4. goals
  5. contact details

The assessment should stay lightweight and decision-support oriented, not installer-grade technical intake.

Step 1: Location​

Purpose:

  • identify the user’s area early
  • validate whether the location is currently serviceable
  • avoid wasting unsupported users’ time

Required fields:

  • postcode

Conditional/required when available:

  • suburb

Derived/system-side field:

  • serviceabilityStatus

Behavior:

  • validate postcode and locality early
  • if the postcode is outside the current supported service area, soft-stop the standard assessment flow
  • soft-stop means:
    • do not continue the full assessment
    • route the user to a lighter fallback path such as contact, register-interest, or manual review messaging

serviceabilityStatus is system-derived, not user-entered.

Step 2: Home Profile​

Purpose:

  • capture enough high-level property context to inform recommendation logic

Required fields:

  • homeType
  • ownershipType
  • storeys
  • roofShading

Optional fields:

  • roofNotes

V1 rule:

  • keep this step high-level
  • do not capture installer-grade technical fields such as pitch, exact orientation matrix, switchboard detail, or panel layout constraints

Step 3: Energy Usage​

Purpose:

  • capture a simple picture of present energy usage and storage interest

Required fields:

  • billRange
  • householdSize
  • daytimeUsageProfile
  • hasExistingSolar
  • batteryInterest

Optional fields:

  • existingSolarNote

V1 rule:

  • use coarse bill/usage bands
  • do not require exact kWh consumption
  • existing solar is captured as simple yes/no plus optional note, not a deep upgrade branch

Step 4: Goals​

Purpose:

  • capture what the user is actually trying to achieve so recommendation framing stays practical

Required field:

  • goals[]

Recommended goal values:

  • reduce_bills
  • energy_independence
  • ev_preparation
  • backup_power
  • upgrade_existing_system
  • just_exploring

goals should support multi-select in V1.

Step 5: Contact Details​

Purpose:

  • collect the required handoff information only after value has been established

Required fields:

  • fullName
  • email
  • phone
  • preferredContactMethod

Optional fields:

  • notes

V1 rule:

  • name, email, and phone are all required
  • contact collection happens at the end of the flow, not before the user has received value

V1 Assessment Fields​

Recommended V1 fields:

  • postcode
  • suburb
  • homeType
  • ownershipType
  • storeys
  • roofShading
  • roofNotes?
  • billRange
  • householdSize
  • daytimeUsageProfile
  • hasExistingSolar
  • existingSolarNote?
  • batteryInterest
  • goals[]
  • fullName
  • email
  • phone
  • preferredContactMethod
  • notes?

Derived/system-side fields:

  • serviceabilityStatus
  • submission metadata
  • timestamps

Contract Boundaries​

These do not belong inside the assessment input contract:

  • selectedPath Belongs after recommendation, not inside intake
  • recommendation outputs Belong in the results contract, not intake
  • lead lifecycle status Belongs in admin/backend workflow, not assessment input

V1 Exclusions​

The assessment does not try to do these things in V1:

  • technical installer-grade roof survey
  • exact quote preparation
  • exact energy consumption inputs as mandatory fields
  • detailed existing-system upgrade workflow branching
  • account creation or save-for-later requirements by default

Validation Scenarios​

The model should support these scenarios:

  • a supported postcode continues into the normal five-step flow
  • an unsupported postcode soft-stops into the fallback path
  • a user can complete the assessment without technical roof detail
  • a user can complete the assessment using bill range rather than exact usage data
  • existing solar can be captured without forcing detailed upgrade logic
  • all three core contact fields are required before final submission
  • selectedPath is not collected inside assessment
  • assessment input stays distinct from recommendation output
  • both first-time solar users and basic existing-solar upgrade inquiries can use the same intake flow