Definitions and Source-of-Truth Change Control (generic process)

Definitions and Source-of-Truth Change Control (generic process) is the generic process card, GP-606, for the one change control shared by The Definitions Register (RG-nnn), the Source of Truth Register (ST-nnn), the definition cards on The Data Definition Card and the lineage cards on Data Lineage Card for Planning Models: propose, review, version and adopt, every change forward only. It is triggered by a proposal from any seat, by a platform, channel or cohort change, or by a finding of GP-605, and produces a new version with an effective date, a signed adoption record and a re-version list for every model the lineage query names. It is part of Process Standardization and of the Workforce Data Definitions Framework, and sits with the cross-cutting governance processes of the function catalog in Anatomy of a ROC Standard, beside GP-601, which governs the standard's text where this card governs the numbers it computes on.

The four steps are stated on The Definitions Register in one paragraph; this card owns the L2. This card maps its steps onto the registration statuses of ISO/IEC 11179-6: Candidate for a proposal received, Preferred Standard for the version adopted, Superseded for the version it replaces, and Retired for a definition no lineage card cites any longer, a retirement test that is the card's own; nothing is deleted. The forward-only rule is the dimensional-modeling treatment of a changed attribute: a new row with an effective date, the old row kept. The carry rule follows: a number computed on the old version keeps its grade as a value of that version and is [A] only when read as a value of the new one; history is never restated.

Process profile

Field	Generic value
Card	GP-606 · local card id assigned by the standards committee at deployment
Class	supporting, in the catalog's four-class vocabulary (strategic · real-time · both · supporting)
Trigger	a change proposal from any seat; a platform, channel or cohort change that invokes the carry rule; a finding from GP-605; a quarantine row on Data Quality Gates for Planning Inputs whose cure needs a new RG or ST version
Cadence	on demand, batched to a review slot (SET LOCALLY; fortnightly is typical [A]); an emergency path for a platform change with a dated cut-over
Scope in	every RG entry, ST row, definition card and lineage card; their versions, effective dates, signatories and change history; the grade a number carries when read as a value of the new version
Scope out	the standard's text and process cards (GP-601); activity-code configuration on a platform (Activity-Code Consistency); the audit that finds the gaps (GP-605); the workshop that agrees a channel's definitions in bulk (Capacity Standards Workshop for Time Accounting), whose outputs enter here as proposals
Inputs	the proposal with its reason; the current version of the affected object; the lineage query result; the carry-rule assessment; the parallel-run result where one was required
Outputs	the new version with effective date; the adoption record; the change-history row; the re-version list of lineage cards with committed dates; the re-grade notice to consuming models and reports
Upstream	GP-605 findings; the capacity standards workshop; the quarantine register; platform migration programs; Forecast Value Added in Workforce Management reviews that find a definitional cause
Downstream	every lineage card citing the changed object; the plan of record (Capacity Planning Cycle); GP-604, whose reports cite the version; GP-602, which reads actuals on the new definition from its effective date
Resources	the two registers and the two card sets; a lineage query over the cards; a change log; the review slot. Platforms are named at L3, never here
Decision points	is the proposal a correction, an extension or a new object? does the change alter a number in a signed plan of record? is a parallel run required, and for how long? is the version adopted, declined or returned?
Authority tier	proposal at any tier; review by the register's owner and the co-owner (seats, not a tier); adoption at tier 4 by the function head, who convenes the signatories; a change that moves a signed plan of record is reported to the executive sponsor, by exception
Risk and compliance flags	a change adopted by one signatory produces the two-definitions trap at the boundary with the others; a change applied retrospectively destroys the record of what a plan was signed on; a contractual definition that differs from the register's is a variant, never a replacement; agent-level time instruments are subject to co-determination and data-protection rules in several jurisdictions
Variant-prone steps	the signatory set where a works council or a client contract holds a say over a definition; the parallel-run length; the emergency path's approver
Automation candidates	ten L2 sub-steps (listed below)

L1 flow

1. Receive and log the proposal (register's owner): the object, the reason, the reports and models the proposer believes it affects.
2. Is this a correction, an extension or a new object? (register's owner): a new object starts as a Candidate.
3. Run the lineage query (data and analytics lead): every card citing the object, then every card citing those cards' outputs, to the plans and reports at the end of each chain.
4. Does the change alter a number already in a signed plan of record? (register's owner): if yes, the plan's owner is told before review, never after.
5. Review against the fields (register's owner, with the co-owner as reviewer): the register fields, the card's added fields, the one-source rule and the conflict rule for an ST row.
6. Is a parallel run required? (register's owner, with the consuming-model owners as reviewers): where a load-bearing number moves, both versions are reported side by side for a stated period (SET LOCALLY; one planning cycle is typical [A]).
7. Draft the new version (register's owner): version number, effective date, previous version kept; the change-history row opened.
8. Assess the carry rule (data and analytics lead): which values are [A] when read on the new version, and which models' outputs drop grade until re-measured.
9. Is the version adopted? (function head, who convenes the signatories and signs at tier 4): adopt, decline with reason, or return for amendment to step 5.
10. Publish and notify (register's owner): registers and cards updated; effective date and re-grade notice sent to every consumer the query named, including GP-604.
11. Re-version the lineage cards (the card owner, per card): by a committed date; a card past its date is a quarantine row on its model's inputs.
12. Close the record (register's owner): change-history row completed; any lesson logged for GP-605's next audit.

L2 step table

Thresholds and system names never appear here; a localizing team sets them at L3.

Step	Sub-step	Owner (seat)	Inputs	Outputs	Duration	Automation candidate	Documentation join key
1	Log the proposal with reason and claimed impact; confirm the object's current version	register's owner	proposal, registers	change record opened	same day [A]	Y	change record id; RG/ST/LN id + version
2	Classify: correction, extension, new object	register's owner	proposal, current version	classification	minutes [A]	N	change record id
3	Query first-order consumers	data and analytics lead	lineage cards	card list	minutes [A]	Y	LN ids
3	Walk the chain to plans and reports	data and analytics lead	card list	impact list with end points	hours [A]	Y	LN ids, plan version, report ids
4	Check the impact list against signed plans of record; notify the affected plan's owner	register's owner	impact list, plan register	plan-impact flag; notice logged	same day [A]	Y	plan version, change record id
5	Review the register fields	register's owner	draft, current version	field-by-field review note	one review slot [A]	N	RG/ST id
5	Check the one-source rule and conflict rule (ST rows); the validation rule and instrument class (cards)	data and analytics lead	ST row or card draft	finding or clear	within the slot [A]	N	ST id; card id
6	Decide whether a parallel run is required and its length	register's owner	impact list, grade assessment, consuming-model owners' review	parallel-run decision (SET LOCALLY)	within the slot [A]	N	change record id
7	Draft the new version with effective date; open the change-history row	register's owner	review note	draft version; history row	hours [A]	Y	RG/ST/LN id + new version
8	List the values that are [A] when read on the new version	data and analytics lead	impact list, grades	re-grade list	hours [A]	Y	LN ids, ledger versions
8	Compute the consuming models' new output grades	data and analytics lead	re-grade list, lineage cards	output-grade list	hours [A]	Y	LN ids
9	Convene the signatories over the draft, the re-grade list and any parallel-run result	function head	draft, re-grade list, parallel-run result	adopt / decline / return	one review slot [A]	N	change record id
9	Record the adoption with the function head's signature and each signatory's	register's owner	decision	adoption record	minutes [A]	N	RG/ST/LN id + version
10	Update the registers and cards; announce the effective date and re-grade to every consumer named by the query	register's owner	adoption record, impact list, output-grade list	published version; notices logged	same day [A]	Y	RG/ST/LN id + version; report ids
11	Re-version the lineage card	card owner	published version	re-versioned card with date	by committed date (SET LOCALLY)	N	LN id + version
11	Track cards past their committed date; raise quarantine rows	register's owner	card dates	quarantine rows	weekly [A]	Y	LN id, quarantine row id
12	Complete the change-history row; close the record; log the lesson	register's owner	all of the above	closed record; lesson entry	minutes [A]	Y	change record id; GP-605 audit id

Variants

Recorded per Standard and Variant in Process Documentation:

• Statutory. In Germany the works council holds a co-determination right over the introduction and use of technical devices designed to monitor the behaviour or performance of employees, which reaches a work-item timer or a focus-time instrument on an agent's desktop; a card's instrument class is constrained there and the works-council liaison joins the signatories for cards that read agent-level time. A variant row, approved by the function head on legal advice.
• Contractual. A client contract that fixes its own definition of handle time or service level for billing holds it as a named variant beside the register's entry, owned by the placement and vendor lead, never as a replacement; the billing report cites the variant, the plan computes on the register. A variant row.
• Structural. A platform instance that cannot emit a field the instrument class assumes parameterizes the ST row's extraction path: SET LOCALLY, no variant row, the gap in the known-gaps field.
• Transitional. A unit from a predecessor organization that still runs its own definition keeps it under a variant row with an expiry at the cut-over date, after which its numbers are [A] when read on the shared definition.

L3 register

Job aid	Anchored to	Form
The proposal form and the change-record template	step 1	work instruction
The lineage query procedure over the card set	step 3	work instruction
The review checklist against the register and card fields	step 5	work instruction
The parallel-run procedure and its reporting template	step 6	playbook
The carry-rule assessment and re-grade template	step 8	work instruction
The adoption record and the signature block	step 9	work instruction
The emergency path for a dated platform cut-over	steps 1 to 10	runbook
The re-version tracker for lineage cards	step 11	work instruction

Automation candidates

The ten L2 sub-steps marked Y, ordered by how easy a catch rate is to publish for each; released per class of action on a published catch rate per Human Gates and Number Grades.

1. The re-version tracker (step 11): a date comparison; every miss is visible the following week.
2. Logging the proposal and confirming the object's version (step 1): ranks after because it reads free text, so a wrongly cited object is caught only at review.
3. Closing the record (step 12): ranks after because a history row's completeness is checked against the whole record, which takes a cycle to audit.
4. The first-order lineage query (step 3): ranks after because its result is only as current as the cards' inputs fields, which step 11 maintains.
5. The chain walk to plans and reports (step 3): ranks after because each additional end point is another place an omission can hide.
6. The plan-impact check and notice (step 4): ranks after because its catch rate is bounded by the currency of a second object, the plan register.
7. Drafting the version and opening the history row (step 7): ranks after because a mis-copied field in the draft is caught only by the signatories.
8. Publishing and announcing (step 10): ranks after because it writes the objects of record, the costliest error to reverse.
9. The re-grade list (step 8): ranks after because the version boundary must be read correctly for every value, and the overseer checks the inputs.
10. The output-grade computation (step 8): ranks last because it compounds the re-grade list with the weakest-input rule across the chain.

Adoption (step 9) is never a candidate. It is a signature by the function head with the signatories whose client portfolios the registers make comparable; a definition adopted by a rule is a private definition with a version number. The data-management literature likewise places the adoption of a definition with named, accountable stewards rather than with the process that applies it.

Maturity Model Position

Four scales on this wiki use the word level; the launch page states which is which. On the WFM Labs Maturity Model™ a function that changes a definition by agreement in a meeting and records the date is at Level 2; one that runs the four steps with a lineage query, forward-only versions and a signed adoption, so that every report cites the version it was computed on, is at Level 3; one that has released the first candidates above on a published catch rate, adoption still human, is at Level 4. The release is on the evidence, not on the level.

See Also

• Workforce Data Definitions Framework — the hub: the ledger, the definitions and the sources this process governs
• Process Standardization — the hub and the inventory this card belongs to
• The Definitions Register — the four steps in one paragraph; the ten fields; the signatories
• Source of Truth Register — the ST rows the process versions; the conflict rule
• The Data Definition Card — the register row in full
• Data Lineage Card for Planning Models — the cards the lineage query reads and re-versions
• Standards Governance and Change Control (generic process) — GP-601, the sibling process for the standard's text
• Time and Production Accounting Audit (generic process) — GP-605, the audit whose findings enter here
• Standard and Variant in Process Documentation — how the variants above are recorded
• Human Gates and Number Grades — the carry rule and the release condition for the candidates