EBX Stewardship Workflows for AI-Ready MDM

Automated evidence moving through assigned stewardship, exception handling, human approval, and immutable audit history. — Part 6: Stewardship Workflows, Roles, and Human Decisions

A golden record is not trusted because an algorithm selected it. It is trusted because the organization can explain who proposed the change, which rules evaluated it, who accepted the residual risk, and what evidence remains afterward.

In Part 5 we resolved duplicate records and applied survivorship. Now we turn that decision logic into an operating system for people. The result of this workshop is a controlled exception workflow in which automation prepares evidence while an accountable steward makes the consequential decision.

Who this workshop is for

Data stewards, MDM product owners, workflow developers, governance leads, security architects, and AI-risk owners implementing the Customer and Product domains from Parts 1–5.

Prerequisites

An isolated EBX 6.2.3 workshop environment with the Customer model, source records, quality rules, and match candidates created earlier in the series.
Permission to create or configure roles, dataspaces, workflow models, and workflow publications.
Three non-production identities—or three browser sessions—for customer-steward, domain-owner, and workflow-monitor.
Synthetic data only. Do not reuse production identities or credentials.

Version note: Menu labels below are written for the classic/advanced EBX 6.2.3 interface. EBX 6.2.3 also documents a preview user interface whose navigation may change. Treat exact labels as environment-specific and verify against your licensed build. The workflow concepts—publication, work item, allocation, monitoring, and history—remain the stable anchors.

Learning outcomes

By the end, you will be able to:

Separate directory roles from workflow permissions and data permissions.
Route an ambiguous match to a steward and a high-risk merge to a domain owner.
Preserve the algorithm's recommendation without treating it as approval.
Define escalation, segregation-of-duties, and validation gates.
Prove which human made the final decision.

The decision boundary

Use AI or probabilistic logic to recommend, summarize, rank, or detect anomalies. Require a human to approve when a decision changes a legal identity, merges histories, suppresses a record, changes a high-impact classification, or overrides a governance rule. “Human in the loop” is not a button; it is a named role, adequate evidence, authority to reject, and an auditable outcome.

Synthetic exception packet

csv

case_id,record_a,record_b,match_score,risk_tier,conflicting_fields,recommendation
MC-006,C-10017,C-90017,0.91,HIGH,"tax_id;country","REVIEW_MERGE"
MC-007,C-10021,C-90021,0.84,MEDIUM,"email","REVIEW_LINK"
MC-008,C-10034,C-90034,0.62,LOW,"name;postal_code","KEEP_SEPARATE"

The score is evidence, not authority. Store the model/rule-set identifier, execution time, contributing signals, and source-record identifiers with the case.

Hands-on: build the decision path — expanded executable procedure

Exact EBX 6.2.3 classic/preview labels and configured services vary; verify them in the licensed environment and work only in isolated non-production data.

Actions: In the approved EBX 6.2.3 directory/configuration interface, create internal roles MDMCUSTOMERSTEWARD, MDMDOMAINOWNER, and MDMWORKFLOWMONITOR; map external groups through approved SSO mapping and assign separate synthetic identities. Configure data, workflow, and monitoring permissions independently. Run every positive and negative cell in the capability matrix. Expected result: steward edits proposals, owner approves high risk, monitor reallocates, and none directly edits production. Validation: retain actor/time/pass-fail evidence. Stop/recovery: remove excessive membership, invalidate sessions, and repeat if any negative test succeeds.

Actions: Snapshot the governed Customer branch, create CUSTOMER-CASE-MC-006, copy only the two candidates and proposed resolution, validate identifiers/counts, and store the dataspace key as a typed workflow context variable. Expected result: changes exist only in the case dataspace. Validation: reference-branch comparison is empty. Stop/recovery: if the parent changed, stop, restore/recreate from snapshot, and investigate access.

Actions: Model start, deterministic evidence check, steward review, risk/override routing, owner approval, validation, merge, correction/close, and end. Allocate tasks to roles. Limit scripts to record existence, required fields, and evidence hashing; scripts never approve. Configure rejection and technical-failure branches, validate, then publish only to the workshop workflow environment. Expected result: no high-risk/override path bypasses owner approval. Validation: inspect every transition and model-validation result. Stop/recovery: keep the prior publication active and correct a new version if validation/publication fails.

Actions: Show both records, score/threshold, conflicts, proposed survivorship, rule/model version, time, and prior decisions. Keep recommendations read-only. Require decision enum, reason code, and rationale; persist recommender separately from human actor. Expected result: a steward can disagree but cannot alter evidence or submit without rationale. Validation: attempt both prohibited operations. Stop/recovery: unpublish the model version if either succeeds and repair form/data permissions.

Actions: Invoke dataspace validation immediately before merge; route HIGH risk and deterministic-identifier overrides to the owner; configure 24-business-hour escalation that allows the monitor to notify/reallocate but never approve; prevent same-case preparer/owner overlap. Expected result: errors, missing approval, and expired time never merge. Validation: inject a validation error, expire a test item, and attempt same-person approval. Stop/recovery: halt launches and revert to the last validated workflow publication on any bypass.

Actions: Launch MC-006; as steward request more evidence, add it, and propose MERGE; as owner reject once; revise as steward; approve as owner; inspect as monitor. Expected result: only the final approved and validated path merges. Validation: reconcile workflow history, actors, allocations, dataspace comparison, and resulting record. Stop/recovery: freeze new launches, preserve failed history, and restore the reference snapshot if it changed unexpectedly.

Validation checklist

Not completed: A steward can see allocated work but cannot approve a high-risk merge.
Not completed: The domain owner can approve or reject but cannot rewrite the steward’s recorded rationale.
Not completed: A monitor can view and reallocate without editing master data.
Not completed: The recommendation, version, evidence, human decision, and actor are distinct fields.
Not completed: Validation failure blocks merge.
Not completed: Rejection leaves the reference branch unchanged.
Not completed: Completed workflow history identifies task, actor, timestamp, and outcome.
Not completed: No timeout path auto-approves a case.

Failure modes to design out

Failure	Why it matters	Control
“AI approved” recorded as the actor	No accountable person	Store recommender and approver separately
Everyone is a steward and owner	Segregation of duties collapses	Distinct roles and permission tests
Email is the workflow	Decisions escape audit and context	Keep action inside the work item
Reassignment changes history	Audit becomes misleading	Append allocation events; never rewrite
Validation runs after merge	Bad data reaches the reference branch	Put validation before the merge transition
SLA expiry equals approval	Silence becomes consent	Escalate; never auto-approve high-impact cases

Takeaway

Good stewardship is a decision architecture: machines organize evidence, people exercise accountable judgment, and the platform preserves both. The most valuable workflow metric is not “items closed.” It is the proportion of decisions that are timely, evidence-backed, policy-compliant, and reversible.

Next in the series

Part 7 turns trusted records into trusted context. We will govern hierarchies and controlled vocabularies so analytics and AI systems know not only *which* entity is correct, but also where it belongs and what its classifications mean.

Illustration brief

Hero concept: A clean editorial workflow diagram with two parallel visual languages: lime machine-generated evidence cards entering from the left, and warm orange human decision gates in the center. The final green governed record exits right with an audit trail beneath it. Include no vendor UI screenshot and no humanoid robot.

Alt text: “Match evidence flows through steward review and domain-owner approval before a validated master record is merged, with every decision recorded in an audit trail.”