Skip to main content

Region And Postcode Ownership Rules

This is the locked V1 region and postcode ownership contract for IED.

Use this as the source of truth for:

  • what a region is in V1
  • how postcode ownership works
  • whether postcode ownership is exclusive
  • how region status affects routing
  • what happens when a postcode is uncovered
  • how postcode reassignment works over time

V1 Ownership Model​

V1 uses first-class admin-managed regions.

Core rules:

  • each postcode belongs to exactly one active owner region at a time
  • postcode ownership is deterministic, not shared
  • postcode ownership is admin-managed
  • postcode ownership may be reassigned later if operations change
  • postcode reassignment replaces the active owner; it does not create multi-region routing

What A Region Is​

A region in V1 is:

  • a business-friendly geographic operating area
  • derived from real geography
  • used to group postcodes, installer relationships, and routing defaults

Regions are not just internal codes and are not skipped in favor of postcode-only routing.

Region Naming​

Region names should be readable operational labels, for example:

  • Northern NSW

V1 naming rule:

  • use business-friendly geographic names
  • keep regions geographically coherent
  • do not force rigid administrative naming if it hurts operational clarity

Region Fields​

Recommended V1 region fields:

  • name
  • state
  • activeStatus
  • serviceNotes
  • postcodeCount
  • preferred installers by region
  • backup installers by region

Region Status Behavior​

Recommended V1 region status values:

  • active
  • inactive

Operational meaning:

  • an active region can receive normal routing for its owned postcodes
  • an inactive region blocks routing for all of its owned postcodes

Region activity is not informational only. It directly affects serviceability and routing eligibility.

Postcode Ownership Rules​

V1 ownership rules:

  • each postcode has exactly one active owner region at a time
  • shared region ownership is not part of V1
  • there is no catch-all fallback region in V1
  • there is no shared “manual review region” as the default ownership model

If a postcode is not assigned to an active region:

  • it is unserviceable by default

Postcode Reassignment​

Postcode ownership may be changed administratively over time.

V1 reassignment rule:

  • a postcode can move from one region to another
  • only one active region owns it at a time
  • reassignment is an admin action, not an automatic routing behavior

V1 does not require postcode ownership history to be modeled as a first-class contract yet.

Contract Boundaries​

These do not belong inside the region/postcode ownership contract:

  • installer tiering belongs in the installer-region relationship contract
  • routing overflow decisions belong in routing logic
  • lead assignment state belongs in the lead assignment / routing contract
  • recommendation output or serviceability messaging copy belong in other contracts

What This Contract Must Support Later​

This contract must support:

  • deterministic serviceability checks from postcode input
  • region filters in admin leads and installers
  • preferred and backup installer mapping by region
  • future regional expansion without replacing the ownership model

Validation Scenarios​

The model should support these scenarios:

  • a postcode maps to exactly one active region
  • an admin can reassign a postcode from one region to another
  • a postcode cannot be actively owned by two regions at once
  • an inactive region makes all of its owned postcodes unavailable
  • an uncovered postcode is treated as unserviceable
  • a region can use business-friendly naming while remaining geographically coherent
  • installer relationships can vary by region without changing postcode ownership rules
  • serviceability checks can rely on region ownership without inventing a catch-all fallback region