Developments

Overview

A development is one phase of activity at a scheme — a planning application, a construction project, a refurbishment. Schemes contain one or more developments; each development is broken down further into one or more uses (e.g. 500 sqm office + 1,000 sqm retail = a single development with two uses).

Most of the rules on a development concern internal consistency: dates have to fall in the right order, sizes have to be non-negative, and once you specify a size you have to specify a unit.

Save is only enabled once you’ve changed something.

Required fields

No fields are required at save time. A development can be created with just a parent scheme and saved blank — it will simply score low for completeness until filled in.

That said, the form treats Type and Status as effectively required: leaving either blank will trigger a validation message asking you to pick one before saving.

Field-level rules

Development name max 255 characters

The Name field rejects values longer than 255 characters with “Development Name too long.”

Development ordinal must be a positive whole number

Each development within a scheme carries an Ordinal (1, 2, 3…) that determines its position. The form defaults the ordinal to 1 if you leave it blank, and rejects 0 or negative.

Sizes can be negative for reductions

The aggregated Gross and Net size fields accept negative numbers — a “Reduction” development represents demolition, which subtracts from the scheme’s total size. Most developments have positive sizes; the negative-allowed rule lets a refurbishment project record “−2,000 sqm of obsolete office removed, +5,000 sqm of new office added” as separate developments.

Whether a Reduction or Extension contributes to the parent scheme’s size depends on its Status — see Schemes → Auto-aggregated sizes for the full per-type table.

Occupancy sizes must be non-negative

The Planning Occupancy and Completion Occupancy size fields (Net, Gross, Local) reject negatives. Occupancy represents “size taken by an occupier”, which can’t go below zero.

Where this lives: src/services/web/src/lib/validation/development.ts.

Cross-field rules

Date ordering: Planned ≤ Start ≤ Completion

The three milestone dates must fall in chronological order:

Start Date cannot be before Planned Date → “Start date cannot be before planned date.”
Completion Date cannot be before Start Date → “Completion date cannot be before start date.”

Either side of a comparison can be blank — the rule only fires when both dates are present. So you can record a planned date and a completion date without a start date in between, but if you fill all three they have to be in order.

Size needs a unit (planning, completion, and uses)

If you enter a value in any of the three size fields below, the matching size-unit dropdown becomes required:

Planning Occupancy → Size → Size Unit required.
Completion Occupancy → Size → Size Unit required.
Each row in the Uses list → if Size is set, the row’s Size Unit is required.

In every case the message reads “Size unit is required when size is specified.”

Occupancy size can’t exceed the sum of use sizes

The development’s Uses list represents how the floor is broken down (office, retail, residential, etc.). Each use has its own size. The development’s Planning Occupancy Size and Completion Occupancy Size represent how much of that floor is taken — so neither can exceed the total of the use sizes.

Try to record more occupancy than there is floor and you’ll see “Size taken cannot exceed the total of uses (X).” with X being the current sum.

The rule only fires when the uses’ sizes are all in compatible units; if one use is in sqm and another in sqft, the comparison is done on raw numbers (matching what the user sees in the form).

Closed date appears when “Is Closed” is ticked

Ticking Is Closed? reveals a Closed Date field below it.

Setting a development to Closed cascades to its scheme

Selecting a closed status on one development copies the status (and ClosedDate) onto every other development on the same scheme, and ticks IsRetired (with the same date) on every occupier event linked to the scheme. Investor events are deliberately not touched — closure is occupant-centric, not deal-centric.

The propagation is one-way: editing a single development back out of the closed status afterwards does not roll the siblings or occupier events back. See Schemes → Scheme closure is derived from Developments.

Conditional UI

Building-type-driven use defaults

When you add a new use to a development, the form pre-selects a Building Use mapped to the development’s parent scheme’s Building Type. For example, a development on a Hotel scheme will default new uses to a hotel-appropriate use rather than a generic office.

This is a starter value, not a constraint — you can change it.

Net vs gross display follows your preference

The Net and Gross size columns are shown according to your Area Basis preference under Settings. If you pick Net, Net values appear first; if you pick Gross, Gross values appear first. The other basis is still available as a secondary column. See Units and display.

On save

Required-field check

There are no hard required fields, so a blank development will save. The completeness score will reflect what’s missing.

Concurrency check

Like every other entity, the save fails with a concurrency error if another user has updated the development since you loaded it. See Concurrent edits.

Aggregations recompute

Once the development is saved, the scheme’s size figures recompute from the sum of all its developments’ sizes. This happens automatically in the SaveChanges interceptor — you’ll see the scheme’s headline size update next time the page refreshes. Reductions (type A.05) and Extensions (type A.04) are filtered by status before being summed — see Schemes → Auto-aggregated sizes for the rules.

After save

A DevelopmentCreated or DevelopmentUpdated event fires.
The parent scheme’s size aggregation re-runs; the scheme list view reflects the new totals.
The development’s completeness score gets recalculated (via the nightly job).
An audit log entry records the change.

Schemes — developments roll up to schemes; the size aggregation rule is documented there.
Investment Events — investment-event size auto-population reads the first development’s first use to pick a unit.
Units and display — net vs gross, sqm vs sqft, how Size appears.
Completeness score — which fields drive the development’s score.
Concurrent edits — RowVersion mechanics.

Where this lives

Frontend validation: src/services/web/src/lib/validation/development.ts
Edit form: src/services/web/src/lib/components/panels/DevelopmentEdit.svelte
Model: src/common/models/Models/Development.cs and DevelopmentUse.cs
Command handlers: src/services/api/app/app.api/Handlers/Commands/Developments/
Size aggregation: [AggregatesFrom] attributes on Scheme.cs and Development.cs, applied by the SizeTriplet interceptor at SaveChanges