Vyuh CDX

Appearance

Entity Master Lifecycle ​

Master-data changes are gated by a versioned workflow. CDX products should use the canonical ApprovalWorkflowDefinition rather than a custom graph per entity type.

Entity States ​

dart
enum EntityStatus {
  draft,
  pendingApproval,
  approved,
  effective,
  superseded,
  archived,
}

The workflow does not own the entity row. Outcome activities apply the status change after a durable decision.

Registration ​

dart
final registration = Workflow.define<EntityDraft, ApprovalResult>(
  code: 'directory.entity_registration',
  version: 1,
  fingerprint: 'directory.entity_registration:v1',
  input: entityDraftCodec,
  output: approvalResultCodec,
  execute: (flow, draft) async {
    final valid = await flow.serviceTask(validate, draft, id: 'validate');
    if (!valid.ok) return ApprovalResult.rejected();

    final decision = await flow.userTask(
      approveRegistration,
      valid,
      id: 'approve',
      title: 'Approve registration',
      assignment: Assignment(roleIds: ['entity_approver']),
    );
    if (!decision.approved) return ApprovalResult.rejected();

    await flow.serviceTask(activate, valid, id: 'activate');
    return ApprovalResult.approved();
  },
);

Modification ​

Create a draft version in an activity, collect assigned edits and approvals, then supersede the previous effective version in another activity. Each side effect uses context.idempotencyKey.

For product master-data, prefer the shared approval family:

dart
ApprovalWorkflowDefinition.standard(
  workflow: const WorkflowRef(
    code: 'directory.entity_master_approval',
    version: 1,
  ),
  digest: 'directory.entity_master_approval:v1',
).buildDefinition();

Blueprint stores the master-data policy. The workflow service executes the pinned version. See CDX Integration.

Audit ​

History records who started the run, who completed each user task, and which activity attempt applied the effect. The inspector can replay that evidence without reading product tables.

See Also ​