Skip to content

Taxonomy or Form Revision

An artifact revision — instantiates Social Reality Construction Audit

Executes an approved change to the actual category infrastructure — labels, form fields, database codes, rubrics, and intake questions — so a revised construction takes hold in the systems people transact through.

Taxonomy or Form Revision is the execution step. It changes the concrete artifacts that carry a category — a dropdown, a database enum, a rubric, an intake question, a code list — and manages the messy rollout: migrating legacy records, updating every downstream system that reads the field, and retraining the people who assign it. It is the only sibling that touches live infrastructure. Where the decision memo decides and the language review flags, this one changes the machinery, so the revised construction is actually the one people encounter.

Example

A nonprofit's donor CRM has long carried a "Head of Household" field that forced every household into one named lead. Acting on an approved decision, a Taxonomy or Form Revision replaces it with a "primary contact(s)" model that allows more than one, remaps the old single-value records into the new structure, updates the mail-merge templates and reports that read the field, adds the new option to the public intake form, and briefs the gift-processing team. The hard part is not the new field; it is the migration and the twenty downstream places that quietly assumed exactly one head. The revision executes the change and stabilizes the new category in the systems that reproduce it day to day.

How it works

The distinguishing discipline is to change the artifact and everything downstream of it:

  • Take the approved decision — the revision implements a choice already made, it does not re-litigate it.
  • Redesign the artifact — the field, label, code, rubric, or intake question.
  • Migrate legacy records — and reconcile the ones that do not map cleanly onto the new scheme.
  • Update every consumer and retrain assigners — the reports, scripts, and integrations that read the category, and the people who apply it.

Tuning parameters

  • Migration strategy — big-bang cutover versus phased dual-running. Dual-running de-risks the change but doubles maintenance during the transition.
  • Legacy-mapping fidelity — force old values into new codes versus mark the unmappable as "unknown." Forcing preserves completeness but fabricates data.
  • Downstream reach — change the field only versus chase every report, script, and integration that reads it. Skipping downstream leaves the old category alive in the plumbing.
  • Backward compatibility — whether to keep old codes readable during the transition period.

When it helps, and when it misleads

Its strength is that it makes a decision real — closing the loop from audit to changed infrastructure, without which the memo is just a document. Its classic misuse is the cosmetic relabel: changing the display name while the old category persists in the database and the reports, so the reality is untouched behind a new word. The mirror failures are a botched migration that silently corrupts historical data, and a revision that outruns its mandate by implementing a change the decision never authorized. The discipline that guards against these is to chase the change all the way downstream and keep an auditable trail of how old values were remapped.

How it implements the components

Taxonomy or Form Revision realizes the execution side of the archetype — it lands the change in the infrastructure that reproduces the category:

  • implementation_revision_pathway — its core: the executed change plus the migration and rollout that make it stick in live systems.
  • institutional_reinforcement_map — it operates on the very forms, codes, and systems that stabilize the category, altering the reinforcement machinery itself.

It does not decide whether the change is warranted (revision_or_preservation_decision → Revision Decision Memo) or diagnose the category in the first place (constructed_category_or_practice → Category Audit).

Notes

Relabel versus rebuild is the standing caution: a display rename with no downstream migration leaves the old construction fully intact. The opposite risk is implementing beyond the mandate — the revision must land the decision it was given, not a broader one it improvises.