Malleable Software: Grows With Them, Goes With Them

In one line: software that cannot absorb change gets replaced, not extended — and the procurement documents we analyse prove it: they are written by organizations escaping systems that couldn’t bend.

This page extends The Trust Machine along the axis of time. The philosophy says: make honest data the rational choice. This page says: keep it rational as the organization reorganizes, the regulator re-mandates, the contracts change, and the people grow — without the client ever having to chase the vendor.

Fossilization: the failure mode

Requirement corpora from operators say it in their own words: hierarchies “fixed at three levels with hardcoded labels,” validation logic “hardcoded today,” status mappings that should be “handled by configuration rather than a release.” Those procurements exist because the last system couldn’t bend. The arc is predictable:

1. A need arises — usually under deadline: an audit finding, a regulator mandate, a reorg, a monsoon, a new contract.
2. The change requires a vendor ticket: triage, quote, schedule — weeks to months.
3. Meanwhile the org works around it: “put it in the remarks column,” an Excel routing sheet, a WhatsApp group. Every workaround is twin-rot; the remarks field becomes the shadow schema.
4. The org learns not to ask. Change frequency drops. The admin who knew why each rule exists retires, and the successor fears touching anything — fossilization from within, because change is illegible, not impossible.
5. Year 5–7: the rip-and-replace RFP.

Malleability is therefore not a feature. It is the platform’s survival strategy — and the client’s system owner has an emotional job we must never violate: never having to say “we must wait for the vendor.”

The malleability ladder

Change requests stratify by blast radius, and each layer belongs to a different owner:

Layer	Examples	Owner	Cadence
L0 Personal	saved views, home tiles, language, defaults	any user, instantly	daily
L1 Team	checklist items, remark templates, team dashboards	supervisor	weekly
L2 Process	form fields, closure-code taxonomies, validation rules, SLA tiers, approval matrices, reports, terminology	process owner	monthly; spikes after incidents, audits, mandates
L3 Structural	hierarchy levels, entity types, domain mappings, tenants/contracts, integrations, rate cards	tenant admin, with platform tooling	quarterly–yearly; reorgs, M&A, new business
L4 Kernel	the engine itself	vendor	rare

The doctrine: the vendor is required only at L4 — and every release pushes capability down the ladder. This is the project-is-a-document thesis restated as a client right: the organization’s operating model — hierarchy, vocabulary, forms, workflows, rules, reports — is data the organization edits, rendered by one shell, never a build.

Governed self-service — malleability without chaos

IT departments lock configuration down because ungoverned sprawl is real. The answer is not locked doors; it is the platform’s own evidence-and-approval machinery applied to change itself:

• Config as a versioned document. Every change is drafted, diffed, previewed against a snapshot of real data, approved by the right role, published, and rollback-able. “No silent rule changes” falls out for free.
• Change records with reasons. Every rule carries why it exists — the incident, audit finding, or mandate that created it; who approved it; when. This is organizational memory, and it is what makes the year-5 successor unafraid to change things. (The Book’s own ADR discipline, applied to the client’s operating model.)
• Impact analysis from the consumer registry. “Every ask has a consumer” (principle 8) doubles as the change-impact map: removing a field warns “consumed by 3 reports and 1 API partner.”
• In-flight migration policy. The separator between toy configurability and the real thing: when a workflow changes, the 2,000 open tickets get an explicit, previewed policy — finish on the old flow, migrate at a stage boundary, or force-migrate with notice.
• Staged rollout. One zone first; organizational change deserves canaries too.

AI is the molding interface

Configuration UIs make change possible; AI makes it accessible:

• Spoken policy becomes drafted config. “From next Monday, every trench closure in monsoon-affected zones needs a reinstatement photo” → a drafted validation rule, its impact analysis, and an approval route. The organization’s spoken policy becomes system behavior in a day — governed, not just fast.
• The system proposes its own remolding. Usage telemetry drives suggestions: a field everyone skips → propose removal (the burden budget enforcing itself); clustered “other”-code free text → propose new closure codes; a recurring rejection cause → propose a validation rule. The mistake-becomes-a-rule flywheel is self-remolding software — always human-approved.
• Reports become conversations. A ministry’s new review format is assembled by asking, not by a change order.

Grows with them, goes with them

Grows. New zones, tenants, contracts, geographies, languages, and whole domains (telecom → gas → water → electricity) onboard as configuration. Scale — a 10× field force — is absorbed by architecture, not projects. Individuals grow too: the technician who becomes a lead carries history, defaults, and a verified work record through the transition.

Goes. The software goes where the work goes — into the field, into the wild, wherever they go. The trench, the basement, the manhole, the monsoon, the island reached by ferry, the dead zone. It lives on the device in the worker’s pocket; capture, guidance, validation — and agent help against on-device models — work fully offline; it sips battery and data, pre-caches tomorrow’s sites tonight, and syncs deterministically when signal returns. Crucially, the molded software travels: the configured workflows, rules, checklists and vocabulary are what the worker carries into the field — malleability is worthless if the tailored system only exists where there is wifi. This is the Everything App commitment stated as a user right: no capability degrades merely because the worker moved.

And at the organization level, goes also means the exit door is unlocked: everything the client built is theirs and exportable — configuration as a human-readable document, data in open formats, rules with their change records. Making leaving easy makes staying likely; it is the two-way trust ledger applied one level up, to the vendor↔client relationship.

The honest vendor-side conflict

Change-request revenue is the misaligned instrument of the vendor relationship: it earns services opex while manufacturing the resentment that produces the year-5 replacement RFP. The aligned model: charge for the platform and its growth, make change cheap and self-served, and reserve professional services for genuinely new capability (L4). The economics improve for the vendor too — configuration scales, services don’t.

Fossilization telemetry

Malleability is measurable. Watch: % of change needs self-served (target >90% within a year) · median need-identified → change-live time, measured client-side · configuration change frequency (a config nobody changes is feared or fossilizing) · rollback rate (low but nonzero means the rails are used and trusted) · shadow-schema indicators — free-text growth in remarks fields, “other”-code usage, spreadsheet exports per week — each one a change request the platform failed to absorb · time-to-onboard a new tenant, contract, or domain · vendor ticket mix shifting from “change a label” toward “new capability.”