Case ID,Requirement ID,Module / integration,Journey / title,Test type,Priority,Screen / entry,Preconditions,Numbered actions / procedure,Expected result,Guide reference,Dependencies / limits,Result,Actual result,Evidence file / record / version,Defect ID,Tester,Profile / domain / tenant,Executed at,Retest result,Cleanup receipt
CORE-01-01,R1-CORE-01,Kernel Core,Maintain shared business records,Module journey,P1,Party directory → Onboard person / Onboard organization,"Use an authorized party steward and a separate model reviewer. Prepare a fictional organization, person and address. Select existing approved country/state/geography values. Do not make the example organization an active tenant merely to verify party maintenance.","Before you act | Required context | 
Screen / entry | Party directory → Onboard person / Onboard organization | 
Who acts | Party steward | 
You need | Use an authorized party steward and a separate model reviewer. Prepare a fictional organization, person and address. Select existing approved country/state/geography values. Do not make the example organization an active tenant merely to verify party maintenance. | 
Steps and field guidance
Before you start: Confirm the party is not already present and select the correct domain/profile.
1. Open Party directory and search by the available identifying fields.
2. Choose Onboard person or Onboard organization. Enter the required identity fields; use a recognizable display or registered name.
3. Complete the contact and address steps where needed. Use Back to review earlier values before final submission.
4. Submit the completed aggregate once. Keep the success receipt or created record reference.
5. Reopen the party in Party directory and inspect names, contacts, addresses and related records.
The party and its related records are saved together. Account enrollment and contact verification remain separate actions.Screen 1Party directory and shared business recordsRetained application capture · illustrative records · earlier UI may differ · select image to enlarge
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The party and its related records are saved together. Account enrollment and contact verification remain separate actions.,documentation/KERNEL_DOCUMENTATION_HUB.html#core-demo/step-1-1,R1-G14,Not run,,,,,,,Not run,
CORE-01-02,R1-CORE-01,Kernel Core,Maintain shared business records,Module journey,P1,Selected party → contacts and addresses,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Selected party → contacts and addresses | 
Who acts | Party steward | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Before you start: Have authority to maintain the selected party.
1. Open Add contacts or address and select the party from the authorized lookup.
2. Enter the new contact or address; check country, state and geography choices rather than entering unrelated reference IDs.
3. Submit and reopen the selected party to confirm the new association.
4. For an existing record correction, open its record action and change only editable fields. Reload after a version conflict before resubmitting.
The additional record is associated with the same party without reassigning another party’s data.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The additional record is associated with the same party without reassigning another party’s data.,documentation/KERNEL_DOCUMENTATION_HUB.html#core-demo/step-1-2,R1-G14,Not run,,,,,,,Not run,
CORE-01-03,R1-CORE-01,Kernel Core,Maintain shared business records,Module journey,P1,Hierarchy and classification workspaces,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Hierarchy and classification workspaces | 
Who acts | Party steward | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Before you start: Use approved relationship types and reference values.
1. Define the necessary relationship type, classification value or classification purpose in the applicable work area.
2. Use Link organizations or Assign classification to select the parent/subject and related record.
3. Open Organization hierarchy or Classification workspace to inspect the resulting relationship.
4. Expand the parent row or tree node to see children; use the selected-record context when making another change.
The relationship is visible as a relationship, rather than being mistaken for a one-to-one field.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The relationship is visible as a relationship, rather than being mistaken for a one-to-one field.",documentation/KERNEL_DOCUMENTATION_HUB.html#core-demo/step-1-3,R1-G14,Not run,,,,,,,Not run,
CORE-01-04,R1-CORE-01,Kernel Core,Maintain shared business records,Module journey,P1,Address and Geography → Country / State / locality,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Address and Geography → Country / State / locality | 
Who acts | Reference-data maker and independent checker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Before you start: Choose an authorized geography steward profile.
1. Create or select the geography level, then define the place at that level.
2. Use Place hierarchy to check the parent-child placement.
3. Assign address geography to the correct address and inspect Address geography workspace.
4. If a lookup has no eligible parent or place, correct the reference definition before retrying the assignment.
Addresses refer to controlled geography records that other modules can reuse.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Addresses refer to controlled geography records that other modules can reuse.,documentation/KERNEL_DOCUMENTATION_HUB.html#core-demo/step-1-4,R1-G14,Not run,,,,,,,Not run,
CORE-02-01,R1-CORE-02,Kernel Core,Publish a state and reason contract,Module journey,P1,State Model Designer / Reason Policy Designer → model publication,"Use an authorized party steward and a separate model reviewer. Prepare a fictional organization, person and address. Select existing approved country/state/geography values. Do not make the example organization an active tenant merely to verify party maintenance.","Before you act | Required context | 
Screen / entry | State Model Designer / Reason Policy Designer → model publication | 
Who acts | Model maker and independent reviewer | 
You need | Use an authorized party steward and a separate model reviewer. Prepare a fictional organization, person and address. Select existing approved country/state/geography values. Do not make the example organization an active tenant merely to verify party maintenance. | 
Steps and field guidance
Before you start: A model steward has prepared the state, transition, reason and applicability definitions.
1. Use State Model Designer and Reason Policy Designer to inspect states, allowed actions, terminal states and required narratives.
2. Open Propose model publication. Choose the model, reason domain and consumer; record the purpose of the proposed version.
3. Inspect Model publications and have a different authorized reviewer check the captured inputs and decision.
4. After publication, use the contextual transition check with the published reference and hash.
5. Give the owning application the exact publication reference; confirm its own configuration binds that version before relying on the new behavior.
An immutable reviewed model is available. Publication alone does not change an unrelated application’s workflow.Screen 2Model publications: selected consumer/version and immutable snapshot details; historical local test interfaceRetained application capture · illustrative records · earlier UI may differ · select image to enlarge
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",An immutable reviewed model is available. Publication alone does not change an unrelated application’s workflow.,documentation/KERNEL_DOCUMENTATION_HUB.html#core-demo/step-2-1,R1-G14,Not run,,,,,,,Not run,
CORE-EX-01,R1-CORE-03,Kernel Core,Exception / recovery,Exception / recovery,P1,Another contact is needed,"Use an authorized party steward and a separate model reviewer. Prepare a fictional organization, person and address. Select existing approved country/state/geography values. Do not make the example organization an active tenant merely to verify party maintenance.","1. Prepare a disposable record exhibiting this condition: Another contact is needed.
2. Add an association to the existing party.
3. Reopen the affected record and its history; verify: Do not create a duplicate party solely to add a second contact.
4. Record actual outcome and supporting record/version or denial evidence.",Do not create a duplicate party solely to add a second contact.,documentation/KERNEL_DOCUMENTATION_HUB.html#core-manual/decision-guide,R1-G14,Not run,,,,,,,Not run,
CORE-EX-02,R1-CORE-03,Kernel Core,Exception / recovery,Exception / recovery,P1,Published model needs a correction,"Use an authorized party steward and a separate model reviewer. Prepare a fictional organization, person and address. Select existing approved country/state/geography values. Do not make the example organization an active tenant merely to verify party maintenance.","1. Prepare a disposable record exhibiting this condition: Published model needs a correction.
2. Prepare a successor publication and review consumer binding.
3. Reopen the affected record and its history; verify: Do not expect edits to source definitions to mutate an immutable publication.
4. Record actual outcome and supporting record/version or denial evidence.",Do not expect edits to source definitions to mutate an immutable publication.,documentation/KERNEL_DOCUMENTATION_HUB.html#core-manual/decision-guide,R1-G14,Not run,,,,,,,Not run,
CORE-EX-03,R1-CORE-03,Kernel Core,Exception / recovery,Exception / recovery,P1,A transition evaluates as allowed,"Use an authorized party steward and a separate model reviewer. Prepare a fictional organization, person and address. Select existing approved country/state/geography values. Do not make the example organization an active tenant merely to verify party maintenance.","1. Prepare a disposable record exhibiting this condition: A transition evaluates as allowed.
2. Continue through the business owner’s actual action and approval policy.
3. Reopen the affected record and its history; verify: Evaluation does not grant approval or execute the change.
4. Record actual outcome and supporting record/version or denial evidence.",Evaluation does not grant approval or execute the change.,documentation/KERNEL_DOCUMENTATION_HUB.html#core-manual/decision-guide,R1-G14,Not run,,,,,,,Not run,
CORE-EX-04,R1-CORE-03,Kernel Core,Exception / recovery,Exception / recovery,P1,Consumer reports stale publication,"Use an authorized party steward and a separate model reviewer. Prepare a fictional organization, person and address. Select existing approved country/state/geography values. Do not make the example organization an active tenant merely to verify party maintenance.","1. Prepare a disposable record exhibiting this condition: Consumer reports stale publication.
2. Compare the bound ID/hash with the current publication.
3. Reopen the affected record and its history; verify: Refresh the governed binding; do not remove the version check.
4. Record actual outcome and supporting record/version or denial evidence.",Refresh the governed binding; do not remove the version check.,documentation/KERNEL_DOCUMENTATION_HUB.html#core-manual/decision-guide,R1-G14,Not run,,,,,,,Not run,
TENANT-01-01,R1-TENANT-01,Tenant Engine,Register and prepare a tenant,Module journey,P0,Tenant onboarding → Onboarding requests,"Prepare a Core organization, eligible tenant type, accountable contact and authorized onboarding maker/reviewer. Use a disposable training tenant code. Use a domain you control only if DNS verification is part of the recorded test. Prepare evidence references rather than arbitrary statements that identity or commercial obligations are satisfied.","Before you act | Required context | 
Screen / entry | Tenant onboarding → Onboarding requests | 
Who acts | Tenant registration maker | 
You need | Prepare a Core organization, eligible tenant type, accountable contact and authorized onboarding maker/reviewer. Use a disposable training tenant code. Use a domain you control only if DNS verification is part of the recorded test. Prepare evidence references rather than arbitrary statements that identity or commercial obligations are satisfied. | 
Steps and field guidance
Before you start: Confirm an eligible tenant type and responsible Core organization exist.
1. Open Tenant onboarding and enter code, name, type, responsible organization and contact details.
2. Supply the onboarding reason, readiness references and target date if applicable.
3. Save the draft when interrupted. Resume the same draft from Onboarding requests.
4. Review the entire request and submit. A different eligible reviewer opens Tenant registration review and records the decision.
5. Open the resulting Tenant onboarding case and identify the next incomplete owner step.
The request has a durable status and review history. Approved registration does not by itself activate the tenant.Screen 1Tenant onboarding reviewRetained application capture · illustrative records · earlier UI may differ · select image to enlarge
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The request has a durable status and review history. Approved registration does not by itself activate the tenant.,documentation/KERNEL_DOCUMENTATION_HUB.html#tenant-demo/step-1-1,R1-G14,Not run,,,,,,,Not run,
TENANT-01-02,R1-TENANT-01,Tenant Engine,Register and prepare a tenant,Module journey,P0,Tenant runtime provisioning / organization binding,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Tenant runtime provisioning / organization binding | 
Who acts | Tenant operator | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Before you start: Registration is approved and the operator is authorized for runtime provisioning.
1. Open Tenant runtime provisioning and select the approved request.
2. Use the offered provisioning/recovery action for that record; inspect the execution result before repeating it.
3. Verify the corresponding Tenant runtime registry entry.
4. Complete Tenant organization binding using the eligible organization reference and inspect the onboarding case again.
The registered tenant has the required runtime and organization references, with failures retained for recovery.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The registered tenant has the required runtime and organization references, with failures retained for recovery.",documentation/KERNEL_DOCUMENTATION_HUB.html#tenant-demo/step-1-2,R1-G14,Not run,,,,,,,Not run,
TENANT-01-03,R1-TENANT-01,Tenant Engine,Register and prepare a tenant,Module journey,P0,Capture identity evidence → identity review,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Capture identity evidence → identity review | 
Who acts | Evidence maker and independent reviewer | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Before you start: Use current authoritative registration information.
1. Open Capture identity evidence and select the target tenant.
2. Enter legal name, registration number, authority, jurisdiction and the HTTPS registry reference.
3. Set review validity and explain the evidence; save, review and submit the draft.
4. Have a different authorized reviewer decide the evidence in Identity evidence review.
5. Run the relevant owner step and inspect its canonical result in Onboarding owner steps.
The tenant’s identity evidence is reviewed and linked to an owner execution. Typed assertions alone do not prove identity.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The tenant’s identity evidence is reviewed and linked to an owner execution. Typed assertions alone do not prove identity.,documentation/KERNEL_DOCUMENTATION_HUB.html#tenant-demo/step-1-3,R1-G14,Not run,,,,,,,Not run,
TENANT-01-04,R1-TENANT-01,Tenant Engine,Register and prepare a tenant,Module journey,P0,Tenant configuration → publication,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Tenant configuration → publication | 
Who acts | Configuration maker and checker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Before you start: An eligible setting definition is available.
1. Open Draft tenant setting and select target tenant and configuration setting.
2. Enter the proposed value, reason and evidence reference. Submit the draft for review.
3. Use Tenant configuration review to inspect the exact proposed value and have an independent reviewer decide.
4. Inspect Tenant configuration versions and Effective tenant configuration after publication.
5. For an environment override or promotion, continue in Tenant Control Plane; keep the source publication reference.
A versioned setting is available to eligible consumers. Environment overrides are tracked separately.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",A versioned setting is available to eligible consumers. Environment overrides are tracked separately.,documentation/KERNEL_DOCUMENTATION_HUB.html#tenant-demo/step-1-4,R1-G14,Not run,,,,,,,Not run,
TENANT-01-05,R1-TENANT-01,Tenant Engine,Register and prepare a tenant,Module journey,P0,Commercial plans / tenant subscriptions,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Commercial plans / tenant subscriptions | 
Who acts | Commercial administrator and reviewer | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Before you start: Use approved terms and an eligible organization-bound tenant.
1. Open Publish commercial plan and enter plan code/name, version, edition, HTTPS terms reference, source owner, external revision, scope and validity.
2. Submit and obtain the required independent commercial review.
3. Open Set up commercial subscription, select the reviewed plan and target tenant, and enter the applicable dates and evidence.
4. Review the proposal through Commercial proposal review, then inspect Commercial subscriptions.
5. Run the commercial owner check before requesting entitlements or lifecycle activation.
Commercial evidence points to an exact plan version and valid subscription, enabling downstream eligibility checks.Screen 2Commercial owner check: missing current subscription is shown as a blocker requiring an owner actionRetained application capture · illustrative records · earlier UI may differ · select image to enlarge
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","Commercial evidence points to an exact plan version and valid subscription, enabling downstream eligibility checks.",documentation/KERNEL_DOCUMENTATION_HUB.html#tenant-demo/step-1-5,R1-G14,Not run,,,,,,,Not run,
TENANT-01-06,R1-TENANT-01,Tenant Engine,Register and prepare a tenant,Module journey,P0,Tenant domains → claim and verification,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Tenant domains → claim and verification | 
Who acts | Domain owner and reviewer | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Before you start: A domain administrator can publish the requested DNS record.
1. Open Tenant domains and create the eligible domain claim.
2. Complete the independent approval and obtain the current DNS TXT challenge.
3. Give the exact challenge to the DNS administrator; after publication use the server verification action.
4. Inspect the result and expiry. Renew an expired challenge and repeat verification using its new value.
5. Activate the domain only when the offered action is eligible; check runtime domain resolution separately from tenant activation.
Domain ownership evidence is recorded by the server. A pending or negative DNS result remains pending.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Domain ownership evidence is recorded by the server. A pending or negative DNS result remains pending.,documentation/KERNEL_DOCUMENTATION_HUB.html#tenant-demo/step-1-6,R1-G14,Not run,,,,,,,Not run,
TENANT-01-07,R1-TENANT-01,Tenant Engine,Register and prepare a tenant,Module journey,P0,Tenant onboarding cases → owner steps,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Tenant onboarding cases → owner steps | 
Who acts | Tenant operator | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Before you start: Current identity, commercial, configuration and environment evidence are available.
1. Open Tenant onboarding cases, select the case and inspect its owner-step statuses.
2. Run only the permitted owner actions and read failed/interrupted results before retrying.
3. Inspect Tenant truth publications for the current version and evidence references.
4. Use Tenant Control Plane for the final independently reviewed activation/restoration process.
5. After changes to sources, revisit the case and effective truth rather than assuming an earlier completed step stays current.
The case exposes the remaining dependencies and the signed, versioned truth used by downstream consumers.Screen 3Tenant onboarding case: saved organization binding, owner-step progress and a blocked readiness resultRetained application capture · illustrative records · earlier UI may differ · select image to enlarge
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The case exposes the remaining dependencies and the signed, versioned truth used by downstream consumers.",documentation/KERNEL_DOCUMENTATION_HUB.html#tenant-demo/step-1-7,R1-G14,Not run,,,,,,,Not run,
TENANT-EX-01,R1-TENANT-02,Tenant Engine,Exception / recovery,Exception / recovery,P0,Draft was saved before interruption,"Prepare a Core organization, eligible tenant type, accountable contact and authorized onboarding maker/reviewer. Use a disposable training tenant code. Use a domain you control only if DNS verification is part of the recorded test. Prepare evidence references rather than arbitrary statements that identity or commercial obligations are satisfied.","1. Prepare a disposable record exhibiting this condition: Draft was saved before interruption.
2. Resume it from Onboarding requests.
3. Reopen the affected record and its history; verify: Preserve the request ID and current revision.
4. Record actual outcome and supporting record/version or denial evidence.",Preserve the request ID and current revision.,documentation/KERNEL_DOCUMENTATION_HUB.html#tenant-manual/decision-guide,R1-G14,Not run,,,,,,,Not run,
TENANT-EX-02,R1-TENANT-02,Tenant Engine,Exception / recovery,Exception / recovery,P0,Identity document is quarantined,"Prepare a Core organization, eligible tenant type, accountable contact and authorized onboarding maker/reviewer. Use a disposable training tenant code. Use a domain you control only if DNS verification is part of the recorded test. Prepare evidence references rather than arbitrary statements that identity or commercial obligations are satisfied.","1. Prepare a disposable record exhibiting this condition: Identity document is quarantined.
2. Resolve Custodia admission and then review eligible evidence.
3. Reopen the affected record and its history; verify: Do not replace quarantine with a typed claim that the document was checked.
4. Record actual outcome and supporting record/version or denial evidence.",Do not replace quarantine with a typed claim that the document was checked.,documentation/KERNEL_DOCUMENTATION_HUB.html#tenant-manual/decision-guide,R1-G14,Not run,,,,,,,Not run,
TENANT-EX-03,R1-TENANT-02,Tenant Engine,Exception / recovery,Exception / recovery,P0,Commercial plan changed after review,"Prepare a Core organization, eligible tenant type, accountable contact and authorized onboarding maker/reviewer. Use a disposable training tenant code. Use a domain you control only if DNS verification is part of the recorded test. Prepare evidence references rather than arbitrary statements that identity or commercial obligations are satisfied.","1. Prepare a disposable record exhibiting this condition: Commercial plan changed after review.
2. Review the new exact version and refresh dependent evidence.
3. Reopen the affected record and its history; verify: An earlier plan approval does not authorize a different contract.
4. Record actual outcome and supporting record/version or denial evidence.",An earlier plan approval does not authorize a different contract.,documentation/KERNEL_DOCUMENTATION_HUB.html#tenant-manual/decision-guide,R1-G14,Not run,,,,,,,Not run,
TENANT-EX-04,R1-TENANT-02,Tenant Engine,Exception / recovery,Exception / recovery,P0,DNS verification succeeded but use is denied,"Prepare a Core organization, eligible tenant type, accountable contact and authorized onboarding maker/reviewer. Use a disposable training tenant code. Use a domain you control only if DNS verification is part of the recorded test. Prepare evidence references rather than arbitrary statements that identity or commercial obligations are satisfied.","1. Prepare a disposable record exhibiting this condition: DNS verification succeeded but use is denied.
2. Check domain status/effective dates, tenant lifecycle and resolver scope.
3. Reopen the affected record and its history; verify: DNS ownership by itself does not grant application access.
4. Record actual outcome and supporting record/version or denial evidence.",DNS ownership by itself does not grant application access.,documentation/KERNEL_DOCUMENTATION_HUB.html#tenant-manual/decision-guide,R1-G14,Not run,,,,,,,Not run,
TENANT-EX-05,R1-TENANT-02,Tenant Engine,Exception / recovery,Exception / recovery,P0,Case shows completion but activation fails,"Prepare a Core organization, eligible tenant type, accountable contact and authorized onboarding maker/reviewer. Use a disposable training tenant code. Use a domain you control only if DNS verification is part of the recorded test. Prepare evidence references rather than arbitrary statements that identity or commercial obligations are satisfied.","1. Prepare a disposable record exhibiting this condition: Case shows completion but activation fails.
2. Inspect fresh owner evidence and expiries.
3. Reopen the affected record and its history; verify: Recorded case progress is a projection, not current activation authority.
4. Record actual outcome and supporting record/version or denial evidence.","Recorded case progress is a projection, not current activation authority.",documentation/KERNEL_DOCUMENTATION_HUB.html#tenant-manual/decision-guide,R1-G14,Not run,,,,,,,Not run,
TCP-01-01,R1-TCP-01,Tenant Control Plane,Prepare and activate an environment,Module journey,P0,Request an environment → Environment control,"Use an eligible registered tenant, an authorized environment maker/operator, a separate checker and current owner evidence. For a walkthrough use the supported non-production environment type. Prepare approved runtime placement facts and plan-support configuration; do not copy another installation’s placement proof.","Before you act | Required context | 
Screen / entry | Request an environment → Environment control | 
Who acts | Environment maker and checker | 
You need | Use an eligible registered tenant, an authorized environment maker/operator, a separate checker and current owner evidence. For a walkthrough use the supported non-production environment type. Prepare approved runtime placement facts and plan-support configuration; do not copy another installation’s placement proof. | 
Steps and field guidance
Before you start: Tenant registration and appropriate operator access are in place.
1. Choose Request an environment and select the target tenant and environment type.
2. Enter environment code, intended use and business reason.
3. Submit and obtain independent review in Environment control.
4. Read the resulting environment state. A DRAFT / UNPROVISIONED registration is not a ready environment.
A governed environment registry entry is available for an eligible deployment plan.Screen 1Environment controlRetained application capture · illustrative records · earlier UI may differ · select image to enlarge
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",A governed environment registry entry is available for an eligible deployment plan.,documentation/KERNEL_DOCUMENTATION_HUB.html#tcp-demo/step-1-1,R1-G14,Not run,,,,,,,Not run,
TCP-01-02,R1-TCP-01,Tenant Control Plane,Prepare and activate an environment,Module journey,P0,Plan local deployment → deployment record,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Plan local deployment → deployment record | 
Who acts | Authorized deployment operator | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Before you start: An eligible registered environment and existing runtime/datastore bindings are available.
1. Open Plan local deployment, select the environment and provide the change reason.
2. Submit the plan and obtain a separate checker decision in Deployment and recovery.
3. Run the offered deployment action. Inspect the actual Core-to-database probe and binding evidence.
4. If interrupted or failed, use the reviewed recovery path with the current record and retry reference.
5. Confirm the environment, endpoint, datastore and configuration evidence match before moving to activation.
The supported shared deployment is bound using current probe evidence; no new cloud infrastructure is implied.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The supported shared deployment is bound using current probe evidence; no new cloud infrastructure is implied.,documentation/KERNEL_DOCUMENTATION_HUB.html#tcp-demo/step-1-2,R1-G14,Not run,,,,,,,Not run,
TCP-01-03,R1-TCP-01,Tenant Control Plane,Prepare and activate an environment,Module journey,P0,Environment configuration → promotion / restoration,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Environment configuration → promotion / restoration | 
Who acts | Configuration maker and checker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Before you start: The source tenant configuration version is independently reviewed.
1. Open Promote environment configuration and select source publication and owned environment.
2. Review the exact source hash and current environment base version.
3. Submit, independently review and publish the new environment version.
4. Inspect Environment configuration and the Core acknowledgement of the resolved hash.
5. To restore, create a new restoration proposal referencing the intended prior values; preserve all intervening history.
The environment receives a governed version. Restoration appends history rather than overwriting it.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The environment receives a governed version. Restoration appends history rather than overwriting it.,documentation/KERNEL_DOCUMENTATION_HUB.html#tcp-demo/step-1-3,R1-G14,Not run,,,,,,,Not run,
TCP-01-04,R1-TCP-01,Tenant Control Plane,Prepare and activate an environment,Module journey,P0,Bind platform residency / Define plan support,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Bind platform residency / Define plan support | 
Who acts | Platform operator and reviewer | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Before you start: Installation-owned placement and an eligible reviewed commercial plan exist.
1. Use Bind platform residency to select the approved local placement/region facts.
2. Use Define plan support to connect the exact plan version to a support profile and routing queue.
3. Obtain independent decisions in Residency and support policies.
4. Inspect Effective residency and support, then run a new configuration/deployment probe if current evidence changed.
Current policy facts can be consumed by environment checks and signed tenant truth.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Current policy facts can be consumed by environment checks and signed tenant truth.,documentation/KERNEL_DOCUMENTATION_HUB.html#tcp-demo/step-1-4,R1-G14,Not run,,,,,,,Not run,
TCP-01-05,R1-TCP-01,Tenant Control Plane,Prepare and activate an environment,Module journey,P0,Current module grants → tenant lifecycle,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Current module grants → tenant lifecycle | 
Who acts | Entitlement maker, checker and lifecycle operator | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Before you start: Identity, commercial, configuration, placement and environment evidence are current.
1. Open Request module entitlement and select tenant, module, Allow/Deny, expiry and reason.
2. Obtain independent approval and verify Current module grants.
3. Open Request activation or restoration and select the verified environment and lifecycle operation.
4. Have a different reviewer inspect the exact evidence, then execute the eligible action.
5. Read the final tenant state and new truth publication. Preparation alone is not activation.
The tenant changes state only when the final evidence checks and transaction succeed.Screen 2Current module grants: entitlement state and request entry; historical local test interfaceRetained application capture · illustrative records · earlier UI may differ · select image to enlarge
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The tenant changes state only when the final evidence checks and transaction succeed.,documentation/KERNEL_DOCUMENTATION_HUB.html#tcp-demo/step-1-5,R1-G14,Not run,,,,,,,Not run,
TCP-02-01,R1-TCP-02,Tenant Control Plane,Close a tenant exit case,Module journey,P0,Tenant exit cases,"Use an eligible registered tenant, an authorized environment maker/operator, a separate checker and current owner evidence. For a walkthrough use the supported non-production environment type. Prepare approved runtime placement facts and plan-support configuration; do not copy another installation’s placement proof.","Before you act | Required context | 
Screen / entry | Tenant exit cases | 
Who acts | Exit-case operator and responsible reviewers | 
You need | Use an eligible registered tenant, an authorized environment maker/operator, a separate checker and current owner evidence. For a walkthrough use the supported non-production environment type. Prepare approved runtime placement facts and plan-support configuration; do not copy another installation’s placement proof. | 
Steps and field guidance
Before you start: An open exit case and verified disposition/retention/evidence-owner records are available.
1. Inspect any legal holds and unresolved custody obligations with their owners.
2. Open Request governed exit closure; choose case, legal basis, verified disposition receipt and accepted closure evidence.
3. Submit the reason and obtain an independent decision against current records.
4. Execute only the offered closure action and inspect its immutable result.
5. Confirm registered non-production environments, truth and entitlements reflect the closure outcome. Preserve all evidence.
Governed closure is recorded without fabricating destruction or overriding holds.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Governed closure is recorded without fabricating destruction or overriding holds.,documentation/KERNEL_DOCUMENTATION_HUB.html#tcp-demo/step-2-1,R1-G14,Not run,,,,,,,Not run,
TCP-EX-01,R1-TCP-03,Tenant Control Plane,Exception / recovery,Exception / recovery,P0,Connectivity probe passes; policyConsumed is false,"Use an eligible registered tenant, an authorized environment maker/operator, a separate checker and current owner evidence. For a walkthrough use the supported non-production environment type. Prepare approved runtime placement facts and plan-support configuration; do not copy another installation’s placement proof.","1. Prepare a disposable record exhibiting this condition: Connectivity probe passes; policyConsumed is false.
2. Complete current residency/support/configuration prerequisites.
3. Reopen the affected record and its history; verify: Connectivity does not equal activation readiness.
4. Record actual outcome and supporting record/version or denial evidence.",Connectivity does not equal activation readiness.,documentation/KERNEL_DOCUMENTATION_HUB.html#tcp-manual/decision-guide,R1-G14,Not run,,,,,,,Not run,
TCP-EX-02,R1-TCP-03,Tenant Control Plane,Exception / recovery,Exception / recovery,P0,Grant expired or plan is cancelled,"Use an eligible registered tenant, an authorized environment maker/operator, a separate checker and current owner evidence. For a walkthrough use the supported non-production environment type. Prepare approved runtime placement facts and plan-support configuration; do not copy another installation’s placement proof.","1. Prepare a disposable record exhibiting this condition: Grant expired or plan is cancelled.
2. Resolve commercial eligibility and propose a valid grant.
3. Reopen the affected record and its history; verify: Do not extend the date directly in an approved row.
4. Record actual outcome and supporting record/version or denial evidence.",Do not extend the date directly in an approved row.,documentation/KERNEL_DOCUMENTATION_HUB.html#tcp-manual/decision-guide,R1-G14,Not run,,,,,,,Not run,
TCP-EX-03,R1-TCP-03,Tenant Control Plane,Exception / recovery,Exception / recovery,P0,Configuration changed after the lifecycle review,"Use an eligible registered tenant, an authorized environment maker/operator, a separate checker and current owner evidence. For a walkthrough use the supported non-production environment type. Prepare approved runtime placement facts and plan-support configuration; do not copy another installation’s placement proof.","1. Prepare a disposable record exhibiting this condition: Configuration changed after the lifecycle review.
2. Refresh readiness and obtain the necessary new decision.
3. Reopen the affected record and its history; verify: The checker approved particular evidence, not any future value.
4. Record actual outcome and supporting record/version or denial evidence.","The checker approved particular evidence, not any future value.",documentation/KERNEL_DOCUMENTATION_HUB.html#tcp-manual/decision-guide,R1-G14,Not run,,,,,,,Not run,
TCP-EX-04,R1-TCP-03,Tenant Control Plane,Exception / recovery,Exception / recovery,P0,Execution response lost,"Use an eligible registered tenant, an authorized environment maker/operator, a separate checker and current owner evidence. For a walkthrough use the supported non-production environment type. Prepare approved runtime placement facts and plan-support configuration; do not copy another installation’s placement proof.","1. Prepare a disposable record exhibiting this condition: Execution response lost.
2. Read lifecycle state, receipt and truth before retry.
3. Reopen the affected record and its history; verify: Avoid a second business transition after a committed first attempt.
4. Record actual outcome and supporting record/version or denial evidence.",Avoid a second business transition after a committed first attempt.,documentation/KERNEL_DOCUMENTATION_HUB.html#tcp-manual/decision-guide,R1-G14,Not run,,,,,,,Not run,
TCP-EX-05,R1-TCP-03,Tenant Control Plane,Exception / recovery,Exception / recovery,P0,Exit blocked by legal hold,"Use an eligible registered tenant, an authorized environment maker/operator, a separate checker and current owner evidence. For a walkthrough use the supported non-production environment type. Prepare approved runtime placement facts and plan-support configuration; do not copy another installation’s placement proof.","1. Prepare a disposable record exhibiting this condition: Exit blocked by legal hold.
2. Resolve through the custody/legal owner.
3. Reopen the affected record and its history; verify: Operational convenience cannot override a hold.
4. Record actual outcome and supporting record/version or denial evidence.",Operational convenience cannot override a hold.,documentation/KERNEL_DOCUMENTATION_HUB.html#tcp-manual/decision-guide,R1-G14,Not run,,,,,,,Not run,
AXIS-01-01,R1-AXIS-01,Axis,Configure and publish a screen experience,Module journey,P1,Screens → selected screen and linked records,"Select a non-production screen already in trusted inventory, its current source version and an eligible owner role. Use author, owner-confirming and independent-review identities as required. Prefer a small label/format change for a walkthrough; retain the current published version so that comparison and supported restoration are possible.","Before you act | Required context | 
Screen / entry | Screens → selected screen and linked records | 
Who acts | Screen administrator | 
You need | Select a non-production screen already in trusted inventory, its current source version and an eligible owner role. Use author, owner-confirming and independent-review identities as required. Prefer a small label/format change for a walkthrough; retain the current published version so that comparison and supported restoration are possible. | 
Steps and field guidance
Before you start: Select a profile with screen inventory access.
1. Open Screens, search for the required screen and expand its row.
2. Inspect component and permission-reference counts, the screen mapping and owner/independent reviews.
3. Open the specific mapping or review you intend to inspect; read the record title and status.
4. Use Back to return to the parent. Do not keep opening the same related-record link expecting it to advance the workflow.
You understand which record is the screen, which is its mapping and which is the decision record.Screen 1Experience version historyRetained application capture · illustrative records · earlier UI may differ · select image to enlarge
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","You understand which record is the screen, which is its mapping and which is the decision record.",documentation/KERNEL_DOCUMENTATION_HUB.html#axis-demo/step-1-1,R1-G13,Not run,,,,,,,Not run,
AXIS-01-02,R1-AXIS-01,Axis,Configure and publish a screen experience,Module journey,P1,Screen Mapping Drafts → Mapping Reviews,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Screen Mapping Drafts → Mapping Reviews | 
Who acts | Mapping author, responsible owner and independent reviewer | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Before you start: The current screen inventory exists and has a designated owner.
1. Open Screen Mapping Drafts or the screen’s mapping action.
2. Select Screen, source version and Responsible Role; enter the change reason.
3. Inspect components and permission references for the actual screen behavior.
4. Save and submit the mapping, then complete the owner-confirmation step.
5. A different eligible reviewer opens Mapping Reviews and records the independent decision.
The mapping has attributable owner and independent review against its exact source inventory.Screen 2Mapping Reviews: submitted revision, responsible role and approved/withdrawn historyRetained application capture · illustrative records · earlier UI may differ · select image to enlarge
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The mapping has attributable owner and independent review against its exact source inventory.,documentation/KERNEL_DOCUMENTATION_HUB.html#axis-demo/step-1-2,R1-G13,Not run,,,,,,,Not run,
AXIS-01-03,R1-AXIS-01,Axis,Configure and publish a screen experience,Module journey,P1,Label Drafts / Label Change History → experience versions,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Label Drafts / Label Change History → experience versions | 
Who acts | Presentation author and reviewer | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Before you start: Use approved mapping dependencies.
1. Create the proposed label change in Label Drafts and inspect its target screen/locale.
2. Complete the required review and inspect Label Change History.
3. Create or revise the experience version and verify its approved mapping/label dependencies.
4. Submit, independently review and publish using the eligible experience actions.
5. Inspect the immutable version and downstream generation readiness.
The experience points to reviewed content; editing a draft does not alter a published version.Screen 3Label Drafts: label text and change reason; this retained capture shows validation blocking a saveRetained application capture · illustrative records · earlier UI may differ · select image to enlarge
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The experience points to reviewed content; editing a draft does not alter a published version.,documentation/KERNEL_DOCUMENTATION_HUB.html#axis-demo/step-1-3,R1-G13,Not run,,,,,,,Not run,
AXIS-01-04,R1-AXIS-01,Axis,Configure and publish a screen experience,Module journey,P1,Experience versions → generation / delivery,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Experience versions → generation / delivery | 
Who acts | Authorized publisher and delivery operator | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Before you start: The exact input version is approved and the generation operator has access.
1. Open Generation Handoffs and choose the eligible approved version.
2. Submit generation and retain the handoff reference.
3. Inspect Dynamic Screen Deliveries for status, output identity and errors.
4. Use the offered activation action only when current approval and artifact checks pass.
5. Open the resulting screen using an intended business profile and verify its menu, fields and actions.
The delivery is tied to approved source authority; generation does not create extra IAM grants.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The delivery is tied to approved source authority; generation does not create extra IAM grants.,documentation/KERNEL_DOCUMENTATION_HUB.html#axis-demo/step-1-4,R1-G13,Not run,,,,,,,Not run,
AXIS-02-01,R1-AXIS-02,Axis,Resolve an invalidated mapping review,Module journey,P1,Mapping Reviews → source revision / history,"Select a non-production screen already in trusted inventory, its current source version and an eligible owner role. Use author, owner-confirming and independent-review identities as required. Prefer a small label/format change for a walkthrough; retain the current published version so that comparison and supported restoration are possible.","Before you act | Required context | 
Screen / entry | Mapping Reviews → source revision / history | 
Who acts | Mapping author and independent reviewer | 
You need | Select a non-production screen already in trusted inventory, its current source version and an eligible owner role. Use author, owner-confirming and independent-review identities as required. Prefer a small label/format change for a walkthrough; retain the current published version so that comparison and supported restoration are possible. | 
Steps and field guidance
Before you start: The page reports source/inventory drift.
1. Open the affected mapping and read the invalidation reason.
2. Refresh or revise the draft from current screen inventory.
3. Compare changed components, labels and permission references.
4. Resubmit and repeat the required owner and independent decisions.
The current mapping is reviewed without reusing a stale approval.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The current mapping is reviewed without reusing a stale approval.,documentation/KERNEL_DOCUMENTATION_HUB.html#axis-demo/step-2-1,R1-G13,Not run,,,,,,,Not run,
AXIS-EX-01,R1-AXIS-03,Axis,Exception / recovery,Exception / recovery,P1,Review says Invalidated,"Select a non-production screen already in trusted inventory, its current source version and an eligible owner role. Use author, owner-confirming and independent-review identities as required. Prefer a small label/format change for a walkthrough; retain the current published version so that comparison and supported restoration are possible.","1. Prepare a disposable record exhibiting this condition: Review says Invalidated.
2. Compare changed source inventory and revise the draft.
3. Reopen the affected record and its history; verify: Resubmit a new cycle against the current inputs.
4. Record actual outcome and supporting record/version or denial evidence.",Resubmit a new cycle against the current inputs.,documentation/KERNEL_DOCUMENTATION_HUB.html#axis-manual/decision-guide,R1-G13,Not run,,,,,,,Not run,
AXIS-EX-02,R1-AXIS-03,Axis,Exception / recovery,Exception / recovery,P1,Owner confirmation denied,"Select a non-production screen already in trusted inventory, its current source version and an eligible owner role. Use author, owner-confirming and independent-review identities as required. Prefer a small label/format change for a walkthrough; retain the current published version so that comparison and supported restoration are possible.","1. Prepare a disposable record exhibiting this condition: Owner confirmation denied.
2. Check effective responsible-role membership, API permission and subject separation.
3. Reopen the affected record and its history; verify: Do not change the owner role just to obtain a convenient approval.
4. Record actual outcome and supporting record/version or denial evidence.",Do not change the owner role just to obtain a convenient approval.,documentation/KERNEL_DOCUMENTATION_HUB.html#axis-manual/decision-guide,R1-G13,Not run,,,,,,,Not run,
AXIS-EX-03,R1-AXIS-03,Axis,Exception / recovery,Exception / recovery,P1,Mapping approved but screen unchanged,"Select a non-production screen already in trusted inventory, its current source version and an eligible owner role. Use author, owner-confirming and independent-review identities as required. Prefer a small label/format change for a walkthrough; retain the current published version so that comparison and supported restoration are possible.","1. Prepare a disposable record exhibiting this condition: Mapping approved but screen unchanged.
2. Inspect experience publication, generation and active delivery.
3. Reopen the affected record and its history; verify: Mapping review alone is not runtime activation.
4. Record actual outcome and supporting record/version or denial evidence.",Mapping review alone is not runtime activation.,documentation/KERNEL_DOCUMENTATION_HUB.html#axis-manual/decision-guide,R1-G13,Not run,,,,,,,Not run,
AXIS-EX-04,R1-AXIS-03,Axis,Exception / recovery,Exception / recovery,P1,Correct label but wrong visibility,"Select a non-production screen already in trusted inventory, its current source version and an eligible owner role. Use author, owner-confirming and independent-review identities as required. Prefer a small label/format change for a walkthrough; retain the current published version so that comparison and supported restoration are possible.","1. Prepare a disposable record exhibiting this condition: Correct label but wrong visibility.
2. Inspect IAM bridge and field/action policies.
3. Reopen the affected record and its history; verify: Presentation metadata is not the security source of truth.
4. Record actual outcome and supporting record/version or denial evidence.",Presentation metadata is not the security source of truth.,documentation/KERNEL_DOCUMENTATION_HUB.html#axis-manual/decision-guide,R1-G13,Not run,,,,,,,Not run,
AXIS-EX-05,R1-AXIS-03,Axis,Exception / recovery,Exception / recovery,P1,A published label must be restored,"Select a non-production screen already in trusted inventory, its current source version and an eligible owner role. Use author, owner-confirming and independent-review identities as required. Prefer a small label/format change for a walkthrough; retain the current published version so that comparison and supported restoration are possible.","1. Prepare a disposable record exhibiting this condition: A published label must be restored.
2. Use a reviewed successor/restoration through supported lifecycle.
3. Reopen the affected record and its history; verify: Preserve prior versions and delivery history.
4. Record actual outcome and supporting record/version or denial evidence.",Preserve prior versions and delivery history.,documentation/KERNEL_DOCUMENTATION_HUB.html#axis-manual/decision-guide,R1-G13,Not run,,,,,,,Not run,
TIMEVAULT-01-01,R1-TIMEVAULT-01,TimeVault,Maintain an effective-dated Country and State,Module journey,P1,Country → Create / record action,Use separate maker/checker identities and disposable Country/State codes. Select a period allowed by the current policy and record the engine’s date/time and interval-end convention. The example dates below are illustrative only; do not use a production master or assume retroactive changes are permitted.,"Before you act | Required context | 
Screen / entry | Country → Create / record action | 
Who acts | Reference-data maker | 
You need | Use separate maker/checker identities and disposable Country/State codes. Select a period allowed by the current policy and record the engine’s date/time and interval-end convention. The example dates below are illustrative only; do not use a production master or assume retroactive changes are permitted. | 
Steps and field guidance
Before you start: Use a master-data maker profile.
1. Open Country and choose the create/change action for the intended record.
2. Enter the code/name and required values, effective date and reason.
3. Read the effective-date preview and confirm the intended interval.
4. Submit and inspect the pending request and Regulix handoff.
5. Have a different eligible reviewer decide; reopen the master to distinguish current from future values.
The proposal and decision are retained and the approved value becomes effective at its intended time.Screen 1Country creation and effective periodRetained application capture · illustrative records · earlier UI may differ · select image to enlarge
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The proposal and decision are retained and the approved value becomes effective at its intended time.,documentation/KERNEL_DOCUMENTATION_HUB.html#timevault-demo/step-1-1,,Not run,,,,,,,Not run,
TIMEVAULT-01-02,R1-TIMEVAULT-01,TimeVault,Maintain an effective-dated Country and State,Module journey,P1,State → Create / record action,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | State → Create / record action | 
Who acts | Reference-data maker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Before you start: The intended Country is approved and available.
1. Open State and select its approved Country.
2. Enter the required State identity and proposed change with the effective date.
3. Inspect and submit the proposal.
4. Complete independent review and confirm the State’s parent and version history.
The State is linked to eligible Country authority and has a traceable temporal version.Screen 2Create State: country association and effective periodRetained application capture · illustrative records · earlier UI may differ · select image to enlarge
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The State is linked to eligible Country authority and has a traceable temporal version.,documentation/KERNEL_DOCUMENTATION_HUB.html#timevault-demo/step-1-2,,Not run,,,,,,,Not run,
TIMEVAULT-01-03,R1-TIMEVAULT-01,TimeVault,Maintain an effective-dated Country and State,Module journey,P1,Originating record → pending proposal / TimeVault Reviews,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Originating record → pending proposal / TimeVault Reviews | 
Who acts | Independent reviewer | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Before you start: Use a separate authorized reviewer identity.
1. Open Temporal Governance or the pending request’s native review link.
2. Compare current/proposed values, dates and reason.
3. Choose the available decision and enter its reason.
4. Return to the master and check that an approval or rejection produced the expected current and historical state.
A rejected proposal does not silently replace current values; a future approval remains scheduled.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",A rejected proposal does not silently replace current values; a future approval remains scheduled.,documentation/KERNEL_DOCUMENTATION_HUB.html#timevault-demo/step-1-3,,Not run,,,,,,,Not run,
TIMEVAULT-01-04,R1-TIMEVAULT-01,TimeVault,Maintain an effective-dated Country and State,Module journey,P1,Country / State → History and viewing date,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Country / State → History and viewing date | 
Who acts | Authorized reader | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Before you start: Have read access to the governed object.
1. Open the record’s version history and select the relevant effective interval.
2. Compare the preserved values, change request and reviewer evidence.
3. For a role requiring TimeVault, open the role in IAM and inspect its exact preserved approval.
4. If the role changed, initiate the new required review rather than reusing old preservation evidence.
Historical values explain the version effective at a given time without overwriting later history.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Historical values explain the version effective at a given time without overwriting later history.,documentation/KERNEL_DOCUMENTATION_HUB.html#timevault-demo/step-1-4,,Not run,,,,,,,Not run,
TIMEVAULT-02-01,R1-TIMEVAULT-02,TimeVault,Slice and Dice an existing period,Module journey,P1,Country or State → selected record → Slice and Dice,Use separate maker/checker identities and disposable Country/State codes. Select a period allowed by the current policy and record the engine’s date/time and interval-end convention. The example dates below are illustrative only; do not use a production master or assume retroactive changes are permitted.,"Before you act | Required context | 
Screen / entry | Country or State → selected record → Slice and Dice | 
Who acts | Reference-data maker and independent reviewer | 
You need | Use separate maker/checker identities and disposable Country/State codes. Select a period allowed by the current policy and record the engine’s date/time and interval-end convention. The example dates below are illustrative only; do not use a production master or assume retroactive changes are permitted. | 
Steps and field guidance
Use a disposable Country and State in an approved UAT scope. Choose a date that your policy permits; the values below are an illustrative planning example, not a promise about interval-edge conventions.
Change | Example dates | Inspect before approval | 
Original version | 1 November 2026 through 30 November 2026 | Existing version and the owner’s end-date convention. | 
Contained correction | 10 November 2026 through 15 November 2026 | Preview every resulting interval; the unchanged prefix/suffix should retain their prior values where the engine splits the range. | 
Open-ended successor | From 1 December 2026 | No-end-date control and the prior interval’s final boundary. | 
1. Open the selected record’s temporal change action and enter the permitted proposed period.
2. Use the effective-period preview; compare before, changed and after periods. Do not assume whether an end boundary is inclusive—read the actual preview.
3. Submit the proposal. A separate reviewer compares all affected intervals and the reason.
4. After approval, inspect the viewing-date result inside and outside the changed period, then inspect preserved history.
5. Repeat for State with an eligible approved Country; inspect the parent association at the relevant dates.
If the preview reports overlap, parent eligibility or date validation errors, resolve them before submission. Do not repair temporal history with direct database edits.Screen 3Country Slice and Dice: proposed period, change reason and three-period previewRetained application capture · illustrative records · earlier UI may differ · select image to enlargeScreen 4State Slice and Dice: parent context and effective-period proposalRetained application capture · illustrative records · earlier UI may differ · select image to enlarge
Check before continuing: Previewed intervals match the intended change; after independent approval, date-specific readback and preserved history agree.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","Previewed intervals match the intended change; after independent approval, date-specific readback and preserved history agree.",documentation/KERNEL_DOCUMENTATION_HUB.html#timevault-demo/step-2-1,,Not run,,,,,,,Not run,
TIMEVAULT-EX-01,R1-TIMEVAULT-03,TimeVault,Exception / recovery,Exception / recovery,P1,Approved successor does not show today,Use separate maker/checker identities and disposable Country/State codes. Select a period allowed by the current policy and record the engine’s date/time and interval-end convention. The example dates below are illustrative only; do not use a production master or assume retroactive changes are permitted.,"1. Prepare a disposable record exhibiting this condition: Approved successor does not show today.
2. Compare today with its effective-from date.
3. Reopen the affected record and its history; verify: Use the intended viewing date; do not submit a duplicate change.
4. Record actual outcome and supporting record/version or denial evidence.",Use the intended viewing date; do not submit a duplicate change.,documentation/KERNEL_DOCUMENTATION_HUB.html#timevault-manual/decision-guide,,Not run,,,,,,,Not run,
TIMEVAULT-EX-02,R1-TIMEVAULT-03,TimeVault,Exception / recovery,Exception / recovery,P1,Contained preview shows unexpected gap/overlap,Use separate maker/checker identities and disposable Country/State codes. Select a period allowed by the current policy and record the engine’s date/time and interval-end convention. The example dates below are illustrative only; do not use a production master or assume retroactive changes are permitted.,"1. Prepare a disposable record exhibiting this condition: Contained preview shows unexpected gap/overlap.
2. Check current intervals and owner boundary convention.
3. Reopen the affected record and its history; verify: Correct the proposal before submission; never repair history by deleting version rows.
4. Record actual outcome and supporting record/version or denial evidence.",Correct the proposal before submission; never repair history by deleting version rows.,documentation/KERNEL_DOCUMENTATION_HUB.html#timevault-manual/decision-guide,,Not run,,,,,,,Not run,
TIMEVAULT-EX-03,R1-TIMEVAULT-03,TimeVault,Exception / recovery,Exception / recovery,P1,State parent lookup is empty,Use separate maker/checker identities and disposable Country/State codes. Select a period allowed by the current policy and record the engine’s date/time and interval-end convention. The example dates below are illustrative only; do not use a production master or assume retroactive changes are permitted.,"1. Prepare a disposable record exhibiting this condition: State parent lookup is empty.
2. Check Country approval, active/effective status and current scope.
3. Reopen the affected record and its history; verify: Create/review the required parent authority first.
4. Record actual outcome and supporting record/version or denial evidence.",Create/review the required parent authority first.,documentation/KERNEL_DOCUMENTATION_HUB.html#timevault-manual/decision-guide,,Not run,,,,,,,Not run,
TIMEVAULT-EX-04,R1-TIMEVAULT-03,TimeVault,Exception / recovery,Exception / recovery,P1,Another maker changed the base,Use separate maker/checker identities and disposable Country/State codes. Select a period allowed by the current policy and record the engine’s date/time and interval-end convention. The example dates below are illustrative only; do not use a production master or assume retroactive changes are permitted.,"1. Prepare a disposable record exhibiting this condition: Another maker changed the base.
2. Reload current version and compare both changes.
3. Reopen the affected record and its history; verify: A stale request should not overwrite intervening approved history.
4. Record actual outcome and supporting record/version or denial evidence.",A stale request should not overwrite intervening approved history.,documentation/KERNEL_DOCUMENTATION_HUB.html#timevault-manual/decision-guide,,Not run,,,,,,,Not run,
TIMEVAULT-EX-05,R1-TIMEVAULT-03,TimeVault,Exception / recovery,Exception / recovery,P1,Request rejected,Use separate maker/checker identities and disposable Country/State codes. Select a period allowed by the current policy and record the engine’s date/time and interval-end convention. The example dates below are illustrative only; do not use a production master or assume retroactive changes are permitted.,"1. Prepare a disposable record exhibiting this condition: Request rejected.
2. Read the decision reason and prepare a corrected proposal.
3. Reopen the affected record and its history; verify: The rejected request remains historical evidence; it is not the effective value.
4. Record actual outcome and supporting record/version or denial evidence.",The rejected request remains historical evidence; it is not the effective value.,documentation/KERNEL_DOCUMENTATION_HUB.html#timevault-manual/decision-guide,,Not run,,,,,,,Not run,
REGULIX-01-01,R1-REGULIX-01,Regulix,Configure decisions and executable work,Module journey,P1,Rule Design → Rule Definitions / decision evaluation,"Prepare a disposable request-review scenario with typed inputs, an approved assignment rule and eligible reviewer, supported action/event definitions and a business key. Use the registered definition and native UUIDs returned by the application. Do not substitute old numeric source IDs when no canonical mapping exists.","Before you act | Required context | 
Screen / entry | Rule Design → Rule Definitions / decision evaluation | 
Who acts | Rule author and independent reviewer | 
You need | Prepare a disposable request-review scenario with typed inputs, an approved assignment rule and eligible reviewer, supported action/event definitions and a business key. Use the registered definition and native UUIDs returned by the application. Do not substitute old numeric source IDs when no canonical mapping exists. | 
Steps and field guidance
Before you start: Use a rules maker with access to the intended definition family.
1. Open Rule Design or DMN and choose the supported definition style.
2. Declare typed inputs, rules/conditions, outputs and applicable hit policy.
3. Validate and evaluate boundary, missing-input and expected-match examples using the isolated preview/test facilities.
4. Submit the exact model for independent review and inspect Rule Definitions after the decision.
5. Rebind dependent processes/cases to the approved UUID/hash through their own review process.
Rule publication and consumer binding remain explicit and versioned.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Rule publication and consumer binding remain explicit and versioned.,documentation/KERNEL_DOCUMENTATION_HUB.html#regulix-demo/step-1-1,,Not run,,,,,,,Not run,
REGULIX-01-02,R1-REGULIX-01,Regulix,Configure decisions and executable work,Module journey,P1,Assignments / Events / SLA Policies,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Assignments / Events / SLA Policies | 
Who acts | Policy author and independent reviewer | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Before you start: Use the appropriate configuration maker and reviewer.
1. Maintain Assignments, Assignment Delegations, Events, SLA Policies and Incident Policies as required.
2. Select controlled event/activity/gateway/merge types and business calendars from Masters.
3. Validate and submit governed changes; obtain independent review where required.
4. Inspect the affected definition bindings and create a reviewed successor when changes are needed.
5. Open SLA Incidents and decision/deployment logs to confirm the intended current behavior.
Configuration remains an explicit dependency of execution rather than a silent change to running history.Screen 1Event Types: active and inactive reference recordsRetained application capture · illustrative records · earlier UI may differ · select image to enlarge
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Configuration remains an explicit dependency of execution rather than a silent change to running history.,documentation/KERNEL_DOCUMENTATION_HUB.html#regulix-demo/step-1-2,,Not run,,,,,,,Not run,
REGULIX-01-03,R1-REGULIX-01,Regulix,Configure decisions and executable work,Module journey,P1,BPMN Design / Case Management Design → definitions,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | BPMN Design / Case Management Design → definitions | 
Who acts | Process author and independent reviewer | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Before you start: Identify business outcome, approved actions/decisions and assignment rules.
1. Open BPMN Design or Case Management Design and name the definition.
2. Add the required stages/activities and connect the permitted transitions or sentries.
3. Bind current approved action plans, decisions, assignments and events; inspect validation feedback.
4. Save the design and inspect its record in Process Definitions or Case Definitions.
5. Use the offered maker proposal/review flow. An independent eligible reviewer decides the exact version before publication/deployment.
An approved, pinned definition can become executable; a saved canvas alone is not a deployed process.Screen 2BPMN Process Design: process name, design canvas and definition entry pointsRetained application capture · illustrative records · earlier UI may differ · select image to enlarge
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","An approved, pinned definition can become executable; a saved canvas alone is not a deployed process.",documentation/KERNEL_DOCUMENTATION_HUB.html#regulix-demo/step-1-3,,Not run,,,,,,,Not run,
REGULIX-01-04,R1-REGULIX-01,Regulix,Configure decisions and executable work,Module journey,P1,Process Instances / Case Instances,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Process Instances / Case Instances | 
Who acts | Authorized starter and runtime operator | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Before you start: An approved current definition and business input are available.
1. Open the definition and use the permitted runtime start action.
2. Provide the required business inputs and correlation values, then submit once.
3. Open Process Instances or Case Instances and locate the returned native instance.
4. Inspect status, progress, variables, assigned work and history.
5. Use the current row version for an eligible update, signal or completion action.
Execution is recorded against the native definition and instance, with stale commands rejected.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","Execution is recorded against the native definition and instance, with stale commands rejected.",documentation/KERNEL_DOCUMENTATION_HUB.html#regulix-demo/step-1-4,,Not run,,,,,,,Not run,
REGULIX-01-05,R1-REGULIX-01,Regulix,Configure decisions and executable work,Module journey,P1,Work Queue → assigned work / Approval Decisions,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Work Queue → assigned work / Approval Decisions | 
Who acts | Assigned task owner or eligible checker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Before you start: The task is pending and assigned to the current user/profile or eligible delegate.
1. Open Work Queue or a record-specific notification link.
2. Inspect the linked business record, task requirements and current assignment.
3. Complete the required review/action with its decision, reason and outputs.
4. Refresh the instance and verify the next checkpoint or terminal state.
5. If the task is already completed, inspect the receipt/history before attempting another submission.
Task completion advances the pinned workflow only when its current guards permit it.Screen 3Work Queue: owner/team search and permitted row actions; this retained view has no assigned entriesRetained application capture · illustrative records · earlier UI may differ · select image to enlarge
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Task completion advances the pinned workflow only when its current guards permit it.,documentation/KERNEL_DOCUMENTATION_HUB.html#regulix-demo/step-1-5,,Not run,,,,,,,Not run,
REGULIX-02-01,R1-REGULIX-02,Regulix,Investigate a waiting instance,Module journey,P1,"Definition, instance and task details / SLA Incidents","Prepare a disposable request-review scenario with typed inputs, an approved assignment rule and eligible reviewer, supported action/event definitions and a business key. Use the registered definition and native UUIDs returned by the application. Do not substitute old numeric source IDs when no canonical mapping exists.","Before you act | Required context | 
Screen / entry | Definition, instance and task details / SLA Incidents | 
Who acts | Runtime operator | 
You need | Prepare a disposable request-review scenario with typed inputs, an approved assignment rule and eligible reviewer, supported action/event definitions and a business key. Use the registered definition and native UUIDs returned by the application. Do not substitute old numeric source IDs when no canonical mapping exists. | 
Steps and field guidance
Before you start: Record the instance ID and selected domain/profile.
1. Compare Process Instances with Process Definitions using the definition identity/version, not only the displayed title.
2. Inspect whether the definition is inactive, unpublished, imported, archived or unavailable to the selected profile.
3. Check required source metadata/alias and native mapping through an authorized operator; do not patch a metadata column merely to force display.
4. For a waiting instance, inspect its current human task, timer, sentry or event dependency.
5. Use the eligible incident/recovery command and inspect its result. Archive only terminal instances through the governed action.
The actual dependency or visibility problem is identified while preserving definition and instance history.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The actual dependency or visibility problem is identified while preserving definition and instance history.,documentation/KERNEL_DOCUMENTATION_HUB.html#regulix-demo/step-2-1,,Not run,,,,,,,Not run,
REGULIX-EX-01,R1-REGULIX-03,Regulix,Exception / recovery,Exception / recovery,P1,Designer saved; start unavailable,"Prepare a disposable request-review scenario with typed inputs, an approved assignment rule and eligible reviewer, supported action/event definitions and a business key. Use the registered definition and native UUIDs returned by the application. Do not substitute old numeric source IDs when no canonical mapping exists.","1. Prepare a disposable record exhibiting this condition: Designer saved; start unavailable.
2. Inspect validation, independent review, publication/deployment and dependency state.
3. Reopen the affected record and its history; verify: Do not label a saved canvas deployed.
4. Record actual outcome and supporting record/version or denial evidence.",Do not label a saved canvas deployed.,documentation/KERNEL_DOCUMENTATION_HUB.html#regulix-manual/decision-guide,,Not run,,,,,,,Not run,
REGULIX-EX-02,R1-REGULIX-03,Regulix,Exception / recovery,Exception / recovery,P1,Historic instance exists; definition absent from grid,"Prepare a disposable request-review scenario with typed inputs, an approved assignment rule and eligible reviewer, supported action/event definitions and a business key. Use the registered definition and native UUIDs returned by the application. Do not substitute old numeric source IDs when no canonical mapping exists.","1. Prepare a disposable record exhibiting this condition: Historic instance exists; definition absent from grid.
2. Compare exact definition identity, active/archive state, imported source and selected-profile visibility.
3. Reopen the affected record and its history; verify: Do not alter metadata merely to force a matching title to appear.
4. Record actual outcome and supporting record/version or denial evidence.",Do not alter metadata merely to force a matching title to appear.,documentation/KERNEL_DOCUMENTATION_HUB.html#regulix-manual/decision-guide,,Not run,,,,,,,Not run,
REGULIX-EX-03,R1-REGULIX-03,Regulix,Exception / recovery,Exception / recovery,P1,Task visible but completion denied,"Prepare a disposable request-review scenario with typed inputs, an approved assignment rule and eligible reviewer, supported action/event definitions and a business key. Use the registered definition and native UUIDs returned by the application. Do not substitute old numeric source IDs when no canonical mapping exists.","1. Prepare a disposable record exhibiting this condition: Task visible but completion denied.
2. Check assignee/delegate, action grant, subject separation, state and version.
3. Reopen the affected record and its history; verify: Queue visibility does not create task authority.
4. Record actual outcome and supporting record/version or denial evidence.",Queue visibility does not create task authority.,documentation/KERNEL_DOCUMENTATION_HUB.html#regulix-manual/decision-guide,,Not run,,,,,,,Not run,
REGULIX-EX-04,R1-REGULIX-03,Regulix,Exception / recovery,Exception / recovery,P1,Signal does not advance work,"Prepare a disposable request-review scenario with typed inputs, an approved assignment rule and eligible reviewer, supported action/event definitions and a business key. Use the registered definition and native UUIDs returned by the application. Do not substitute old numeric source IDs when no canonical mapping exists.","1. Prepare a disposable record exhibiting this condition: Signal does not advance work.
2. Inspect pinned event, scope, business key and current wait point.
3. Reopen the affected record and its history; verify: Do not invent arbitrary activity IDs or override gateways.
4. Record actual outcome and supporting record/version or denial evidence.",Do not invent arbitrary activity IDs or override gateways.,documentation/KERNEL_DOCUMENTATION_HUB.html#regulix-manual/decision-guide,,Not run,,,,,,,Not run,
REGULIX-EX-05,R1-REGULIX-03,Regulix,Exception / recovery,Exception / recovery,P1,SLA test passes but incident remains,"Prepare a disposable request-review scenario with typed inputs, an approved assignment rule and eligible reviewer, supported action/event definitions and a business key. Use the registered definition and native UUIDs returned by the application. Do not substitute old numeric source IDs when no canonical mapping exists.","1. Prepare a disposable record exhibiting this condition: SLA test passes but incident remains.
2. Distinguish isolated authoring test from live checkpoint evaluation.
3. Reopen the affected record and its history; verify: Use server-evaluated live state and eligible recovery.
4. Record actual outcome and supporting record/version or denial evidence.",Use server-evaluated live state and eligible recovery.,documentation/KERNEL_DOCUMENTATION_HUB.html#regulix-manual/decision-guide,,Not run,,,,,,,Not run,
REGULIX-EX-06,R1-REGULIX-03,Regulix,Exception / recovery,Exception / recovery,P1,Changed rule needed for new work,"Prepare a disposable request-review scenario with typed inputs, an approved assignment rule and eligible reviewer, supported action/event definitions and a business key. Use the registered definition and native UUIDs returned by the application. Do not substitute old numeric source IDs when no canonical mapping exists.","1. Prepare a disposable record exhibiting this condition: Changed rule needed for new work.
2. Publish the rule successor and review the consumer binding.
3. Reopen the affected record and its history; verify: Existing instances remain accountable to their pinned definitions.
4. Record actual outcome and supporting record/version or denial evidence.",Existing instances remain accountable to their pinned definitions.,documentation/KERNEL_DOCUMENTATION_HUB.html#regulix-manual/decision-guide,,Not run,,,,,,,Not run,
NEXORA-01-01,R1-NEXORA-01,Nexora,Publish and assign learning,Module journey,P1,Content authoring → content review and publication,"Use an author, a separate eligible content/compliance reviewer, a training manager and a learner. Prepare a short approved text lesson, a supported assessment, completion criteria and a controlled training audience. Keep sensitive learner data out of walkthrough screenshots.","Before you act | Required context | 
Screen / entry | Content authoring → content review and publication | 
Who acts | Content author and independent reviewer | 
You need | Use an author, a separate eligible content/compliance reviewer, a training manager and a learner. Prepare a short approved text lesson, a supported assessment, completion criteria and a controlled training audience. Keep sensitive learner data out of walkthrough screenshots. | 
Steps and field guidance
Before you start: Use an author profile and approved source materials.
1. Open Content studio and create/select the content draft.
2. Enter content, supported text/media links and required metadata; preview the learner presentation.
3. Submit to Content reviews and, where required, Compliance reviews.
4. Respond to changes in the draft and repeat the applicable review.
5. Use Learning publication for the eligible reviewed version and verify learner visibility.
Learners receive governed content; an author’s draft is not silently published.Screen 1Content authoring: edit the learning definitionRetained application capture · illustrative records · earlier UI may differ · select image to enlargeScreen 2Content review: hand the saved version to its independent reviewerRetained application capture · illustrative records · earlier UI may differ · select image to enlarge
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Learners receive governed content; an author’s draft is not silently published.,documentation/KERNEL_DOCUMENTATION_HUB.html#nexora-demo/step-1-1,R1-G10,Not run,,,,,,,Not run,
NEXORA-01-02,R1-NEXORA-01,Nexora,Publish and assign learning,Module journey,P1,Training assignments / campaigns,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Training assignments / campaigns | 
Who acts | Training administrator | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Before you start: Identify the intended learners and approved learning items.
1. Open Training assignments or Training campaigns.
2. Select the permitted audience, learning item/path and dates.
3. Review and save/submit the proposed assignment using the available controls.
4. Inspect assignment and campaign progress in the workspace and Learning intelligence.
5. Use in-app due dates/reminders for current visibility; do not assume unconfigured outbound messages were sent.
The intended audience and completion evidence are visible to authorized managers.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The intended audience and completion evidence are visible to authorized managers.,documentation/KERNEL_DOCUMENTATION_HUB.html#nexora-demo/step-1-2,R1-G10,Not run,,,,,,,Not run,
NEXORA-02-01,R1-NEXORA-02,Nexora,Complete and assess learning,Module journey,P1,My learning → assigned item,"Use an author, a separate eligible content/compliance reviewer, a training manager and a learner. Prepare a short approved text lesson, a supported assessment, completion criteria and a controlled training audience. Keep sensitive learner data out of walkthrough screenshots.","Before you act | Required context | 
Screen / entry | My learning → assigned item | 
Who acts | Learner | 
You need | Use an author, a separate eligible content/compliance reviewer, a training manager and a learner. Prepare a short approved text lesson, a supported assessment, completion criteria and a controlled training audience. Keep sensitive learner data out of walkthrough screenshots. | 
Steps and field guidance
Before you start: Choose the intended learner profile.
1. Open Learning home or Course catalog and inspect eligible courses.
2. Open the selected course, review its content and any enrollment/assignment requirements.
3. Use My learning to resume the current item and follow its required activities.
4. Complete an assessment or simulation when offered and inspect the persisted result.
5. Check My certificates for any credential actually issued after the required completion conditions.
Learning progress and results are recorded; opening a course does not automatically satisfy it.Screen 3Learning completion: acknowledgment, feedback and certificate entry pointRetained application capture · illustrative records · earlier UI may differ · select image to enlarge
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Learning progress and results are recorded; opening a course does not automatically satisfy it.,documentation/KERNEL_DOCUMENTATION_HUB.html#nexora-demo/step-2-1,R1-G10,Not run,,,,,,,Not run,
NEXORA-02-02,R1-NEXORA-02,Nexora,Complete and assess learning,Module journey,P1,Written-response / competency review,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Written-response / competency review | 
Who acts | Assigned assessor | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Before you start: Use an eligible reviewer or manager profile.
1. Open Written-answer review and select an assigned response.
2. Inspect the question, response and scoring criteria before recording the review.
3. Open Competencies & readiness or Policies & mappings to inspect the linked evidence.
4. Use Evidence & audit to trace material decisions and changes.
Assessment decisions and readiness evidence retain their source context.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Assessment decisions and readiness evidence retain their source context.,documentation/KERNEL_DOCUMENTATION_HUB.html#nexora-demo/step-2-2,R1-G10,Not run,,,,,,,Not run,
NEXORA-02-03,R1-NEXORA-02,Nexora,Complete and assess learning,Module journey,P1,Sessions / discussions / credentials,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Sessions / discussions / credentials | 
Who acts | Session operator, moderator or credential administrator | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Before you start: Required session details and credential policy are configured.
1. Use Live sessions for in-person or existing meeting-link sessions where supported.
2. Use Discussions and Learning help for permitted collaboration and guidance.
3. In Credential registry, inspect issued, expired or revoked credentials and use the permitted governance actions.
4. For AI mentor or SCORM-dependent content, confirm provider/host configuration before scheduling a walkthrough.
Supported learning paths remain usable while unconfigured external capabilities are visible as dependencies.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Supported learning paths remain usable while unconfigured external capabilities are visible as dependencies.,documentation/KERNEL_DOCUMENTATION_HUB.html#nexora-demo/step-2-3,R1-G10,Not run,,,,,,,Not run,
NEXORA-EX-01,R1-NEXORA-03,Nexora,Exception / recovery,Exception / recovery,P1,Learner cannot see the lesson,"Use an author, a separate eligible content/compliance reviewer, a training manager and a learner. Prepare a short approved text lesson, a supported assessment, completion criteria and a controlled training audience. Keep sensitive learner data out of walkthrough screenshots.","1. Prepare a disposable record exhibiting this condition: Learner cannot see the lesson.
2. Check publication, assignment/enrollment eligibility and current profile.
3. Reopen the affected record and its history; verify: Author visibility is not learner availability.
4. Record actual outcome and supporting record/version or denial evidence.",Author visibility is not learner availability.,documentation/KERNEL_DOCUMENTATION_HUB.html#nexora-manual/decision-guide,R1-G10,Not run,,,,,,,Not run,
NEXORA-EX-02,R1-NEXORA-03,Nexora,Exception / recovery,Exception / recovery,P1,Course viewed but still incomplete,"Use an author, a separate eligible content/compliance reviewer, a training manager and a learner. Prepare a short approved text lesson, a supported assessment, completion criteria and a controlled training audience. Keep sensitive learner data out of walkthrough screenshots.","1. Prepare a disposable record exhibiting this condition: Course viewed but still incomplete.
2. Inspect required activities, assessment and review status.
3. Reopen the affected record and its history; verify: Viewing is not the same as satisfying completion rules.
4. Record actual outcome and supporting record/version or denial evidence.",Viewing is not the same as satisfying completion rules.,documentation/KERNEL_DOCUMENTATION_HUB.html#nexora-manual/decision-guide,R1-G10,Not run,,,,,,,Not run,
NEXORA-EX-03,R1-NEXORA-03,Nexora,Exception / recovery,Exception / recovery,P1,Assessment waiting for review,"Use an author, a separate eligible content/compliance reviewer, a training manager and a learner. Prepare a short approved text lesson, a supported assessment, completion criteria and a controlled training audience. Keep sensitive learner data out of walkthrough screenshots.","1. Prepare a disposable record exhibiting this condition: Assessment waiting for review.
2. Open the assigned written-answer review and apply the rubric.
3. Reopen the affected record and its history; verify: Do not infer a final score from submission alone.
4. Record actual outcome and supporting record/version or denial evidence.",Do not infer a final score from submission alone.,documentation/KERNEL_DOCUMENTATION_HUB.html#nexora-manual/decision-guide,R1-G10,Not run,,,,,,,Not run,
NEXORA-EX-04,R1-NEXORA-03,Nexora,Exception / recovery,Exception / recovery,P1,No reminder email,"Use an author, a separate eligible content/compliance reviewer, a training manager and a learner. Prepare a short approved text lesson, a supported assessment, completion criteria and a controlled training audience. Keep sensitive learner data out of walkthrough screenshots.","1. Prepare a disposable record exhibiting this condition: No reminder email.
2. Inspect current provider/event/template configuration and delivery evidence.
3. Reopen the affected record and its history; verify: The recorded integration gap must not be concealed by an in-app due date.
4. Record actual outcome and supporting record/version or denial evidence.",The recorded integration gap must not be concealed by an in-app due date.,documentation/KERNEL_DOCUMENTATION_HUB.html#nexora-manual/decision-guide,R1-G10,Not run,,,,,,,Not run,
NEXORA-EX-05,R1-NEXORA-03,Nexora,Exception / recovery,Exception / recovery,P1,Credential expired or revoked,"Use an author, a separate eligible content/compliance reviewer, a training manager and a learner. Prepare a short approved text lesson, a supported assessment, completion criteria and a controlled training audience. Keep sensitive learner data out of walkthrough screenshots.","1. Prepare a disposable record exhibiting this condition: Credential expired or revoked.
2. Inspect registry history and the governing validity decision.
3. Reopen the affected record and its history; verify: A downloaded old copy does not establish current validity.
4. Record actual outcome and supporting record/version or denial evidence.",A downloaded old copy does not establish current validity.,documentation/KERNEL_DOCUMENTATION_HUB.html#nexora-manual/decision-guide,R1-G10,Not run,,,,,,,Not run,
ATLAS-01-01,R1-ATLAS-01,Kernel Atlas,Maintain knowledge and prepare a controlled edition,Module journey,P1,Administrator-provided Atlas portal → workspace / Document View,"Choose the Kernel product/workspace and a non-sensitive module claim. Identify an authoritative source document, an implementation artifact and an applicable verification record if one exists. Establish the intended audience before sharing or exporting internal records.","Before you act | Required context | 
Screen / entry | Administrator-provided Atlas portal → workspace / Document View | 
Who acts | Authorized knowledge reader | 
You need | Choose the Kernel product/workspace and a non-sensitive module claim. Identify an authoritative source document, an implementation artifact and an applicable verification record if one exists. Establish the intended audience before sharing or exporting internal records. | 
Steps and field guidance
Before you start: The Atlas administrator supplies the current portal and authorized access.
1. Sign in through the portal’s configured method.
2. Confirm organization, workspace and product/module/release context.
3. Ask the documentation owner to identify the accepted baseline and current review workflow.
4. Check that visible records and exports are limited to the intended scope.
5. Record any mismatch between the portal and this baseline guide before using it for training.
The user is working in a verified project scope; this step is required because current portal behavior was not observed here.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The user is working in a verified project scope; this step is required because current portal behavior was not observed here.,documentation/KERNEL_DOCUMENTATION_HUB.html#atlas-demo/step-1-1,R1-G11,Not run,,,,,,,Not run,
ATLAS-01-02,R1-ATLAS-01,Kernel Atlas,Maintain knowledge and prepare a controlled edition,Module journey,P1,Module / document / section and linked knowledge records,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Module / document / section and linked knowledge records | 
Who acts | Knowledge author and independent reviewer | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Before you start: Use the current portal’s actual authoring controls and approved record taxonomy.
1. Choose the appropriate record type and scope.
2. Capture clear content and authoritative source/evidence references.
3. Link related requirements, architecture, interfaces, models and acceptance evidence using the portal’s supported relationship controls.
4. Submit the revision to the configured review/approval workflow.
5. Confirm its actual approved state and retained history before citing it as a baseline.
The baseline expects attributable, reviewed structured knowledge; exact available actions require portal validation.Screen 1Atlas Document View: historical synthetic fixture, including rejection of self-approval; current portal validation remains requiredRetained application capture · illustrative records · earlier UI may differ · select image to enlarge
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The baseline expects attributable, reviewed structured knowledge; exact available actions require portal validation.",documentation/KERNEL_DOCUMENTATION_HUB.html#atlas-demo/step-1-2,R1-G11,Not run,,,,,,,Not run,
ATLAS-01-03,R1-ATLAS-01,Kernel Atlas,Maintain knowledge and prepare a controlled edition,Module journey,P1,Publications → chosen baseline / output,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Publications → chosen baseline / output | 
Who acts | Authorized knowledge publisher | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Before you start: The documentation owner confirms the current generation/publishing feature is available.
1. Select the intended approved baseline and publication scope.
2. Review coverage and unresolved findings before generating output.
3. Generate the supported editable/read-only formats and inspect them against the source records.
4. Complete the actual publication review and record the output version.
5. Give readers the permitted published artifact rather than an unlabelled draft.
Publication carries a defined baseline and review status; file availability alone is not acceptance.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Publication carries a defined baseline and review status; file availability alone is not acceptance.,documentation/KERNEL_DOCUMENTATION_HUB.html#atlas-demo/step-1-3,R1-G11,Not run,,,,,,,Not run,
ATLAS-EX-01,R1-ATLAS-02,Kernel Atlas,Exception / recovery,Exception / recovery,P1,Source exists but verification is absent,"Choose the Kernel product/workspace and a non-sensitive module claim. Identify an authoritative source document, an implementation artifact and an applicable verification record if one exists. Establish the intended audience before sharing or exporting internal records.","1. Prepare a disposable record exhibiting this condition: Source exists but verification is absent.
2. Describe the capability as specified/source-confirmed, with its verification gap.
3. Reopen the affected record and its history; verify: Do not label it operationally accepted.
4. Record actual outcome and supporting record/version or denial evidence.",Do not label it operationally accepted.,documentation/KERNEL_DOCUMENTATION_HUB.html#atlas-manual/decision-guide,R1-G11,Not run,,,,,,,Not run,
ATLAS-EX-02,R1-ATLAS-02,Kernel Atlas,Exception / recovery,Exception / recovery,P1,Portal differs from the retained instructions,"Choose the Kernel product/workspace and a non-sensitive module claim. Identify an authoritative source document, an implementation artifact and an applicable verification record if one exists. Establish the intended audience before sharing or exporting internal records.","1. Prepare a disposable record exhibiting this condition: Portal differs from the retained instructions.
2. Use administrator-confirmed controls and update the procedure after checking.
3. Reopen the affected record and its history; verify: Keep the old edition dated for traceability.
4. Record actual outcome and supporting record/version or denial evidence.",Keep the old edition dated for traceability.,documentation/KERNEL_DOCUMENTATION_HUB.html#atlas-manual/decision-guide,R1-G11,Not run,,,,,,,Not run,
ATLAS-EX-03,R1-ATLAS-02,Kernel Atlas,Exception / recovery,Exception / recovery,P1,Two modules appear to own the same fact,"Choose the Kernel product/workspace and a non-sensitive module claim. Identify an authoritative source document, an implementation artifact and an applicable verification record if one exists. Establish the intended audience before sharing or exporting internal records.","1. Prepare a disposable record exhibiting this condition: Two modules appear to own the same fact.
2. Use the crosswalk and owner contracts to resolve responsibility.
3. Reopen the affected record and its history; verify: Do not create duplicate authoritative data merely to simplify documentation.
4. Record actual outcome and supporting record/version or denial evidence.",Do not create duplicate authoritative data merely to simplify documentation.,documentation/KERNEL_DOCUMENTATION_HUB.html#atlas-manual/decision-guide,R1-G11,Not run,,,,,,,Not run,
ATLAS-EX-04,R1-ATLAS-02,Kernel Atlas,Exception / recovery,Exception / recovery,P1,Internal evidence included in export,"Choose the Kernel product/workspace and a non-sensitive module claim. Identify an authoritative source document, an implementation artifact and an applicable verification record if one exists. Establish the intended audience before sharing or exporting internal records.","1. Prepare a disposable record exhibiting this condition: Internal evidence included in export.
2. Check audience and visibility before distribution.
3. Reopen the affected record and its history; verify: Retain safe references without exposing secrets or private business data.
4. Record actual outcome and supporting record/version or denial evidence.",Retain safe references without exposing secrets or private business data.,documentation/KERNEL_DOCUMENTATION_HUB.html#atlas-manual/decision-guide,R1-G11,Not run,,,,,,,Not run,
IAM-01-01,R1-IAM-01,Identity and Access Management,Set up the access masters and mappings,Module journey,P0,Authorization → Domains → Create Domain,"Use existing master screens and approved, narrowly scoped demo access. Prepare a maker and a different checker identity, an intended domain/profile and a non-sensitive walkthrough screen. Record the existing grant chain before adding mappings. Do not use one account with two profiles as evidence of independent approval.","Before you act | Required context | 
Screen / entry | Authorization → Domains → Create Domain | 
Who acts | Maker | 
You need | Use existing master screens and approved, narrowly scoped demo access. Prepare a maker and a different checker identity, an intended domain/profile and a non-sensitive walkthrough screen. Record the existing grant chain before adding mappings. Do not use one account with two profiles as evidence of independent approval. | 
Steps and field guidance
Who: Maker
Open: Authorization → Domains → Create Domain
1. Search for DEMO_OPERATIONS or the chosen suffixed code. Reuse only an intentionally prepared example record.
2. Select Create Domain. Enter the following values in the full-page form.
3. Choose the appropriate offered access reason if your setup requires it. For Department Division, do not invent a Provider reference.
4. Use future or current validity dates appropriate to the live run; blank dates and date limits follow the configured form rules.
5. Select Save. On the metadata-backed form, Save submits the complete record for independent approval. A fallback form can label the action Submit for Approval.
6. Record the proposal reference. Have the independent Checker review the creation as described in the review chapter, then refresh Domains.
Field | Example / instruction | 
Domain Code | DEMO_OPERATIONS | 
Domain Name | Operations | 
Domain Type | Department Division | 
Description | Reference-data setup: reference data access in the Operations domain. | 
Provider / Owner Reference | Only when relevant and offered for the selected domain type | 
Access Reason / Remarks | Use approved catalog reason when applicable; short explanatory remarks | 
Start Date / End Date | Business validity; the form describes local-midnight handling | 
Business Reason | Reference-data setup: configure reviewed reference-data reader access. | 
Screen 1Create Domain: complete the actual master formCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• Domain Type and Description are part of the master definition.
• Save creates an approval proposal, not an immediate universal access grant.
Screen 2Domain master after an illustrative approved setupCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• The master grid remains a master grid.
• Relationship actions add eligibility without replacing the domain definition.
Expected result
After a confirmed approval, the domain is available for eligible profile setup. Creating it does not add users, roles or permissions.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","After a confirmed approval, the domain is available for eligible profile setup. Creating it does not add users, roles or permissions.",documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-1-1,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-01-02,R1-IAM-01,Identity and Access Management,Set up the access masters and mappings,Module journey,P0,Authorization → Roles → Create Role,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Authorization → Roles → Create Role | 
Who acts | Maker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Maker
Open: Authorization → Roles → Create Role
1. Select Create Role.
2. Enter Role Code DEMO_READ_ROLE and Role Name Reference data reader role.
3. Select Role Type: Regular for this business walkthrough. Enter Description: Read approved reference data without maintaining it.
4. Complete dates, catalog reason and remarks only as applicable. Add a Business Reason.
5. Select Save and obtain the independent creation decision. Refresh Roles and locate the approved role.
6. Open its details. Note that a role without permission grants cannot perform the intended business actions.
Screen 3Create a regular business roleCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• The role definition and its later permission grants are different changes.
• System/Regular classifies the role; it is not an administrator-access shortcut.
Screen 4Role master and relationship entry pointsCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• Use the role’s record details for Role Permissions.
• Use row mappings/Menu Access for relationships to profiles and screen actions.
Expected result
The role exists after approval. It still needs the intended effective permission grants and a profile relationship.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The role exists after approval. It still needs the intended effective permission grants and a profile relationship.,documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-1-2,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-01-03,R1-IAM-01,Identity and Access Management,Set up the access masters and mappings,Module journey,P0,Authorization → Profiles → Create Profile,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Authorization → Profiles → Create Profile | 
Who acts | Maker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Maker
Open: Authorization → Profiles → Create Profile
1. Select Create Profile. Enter Profile Code DEMO_READER and Profile Name Reference data reader.
2. Choose Initial Domain: Operations. The domain must be available and permitted to this operator.
3. Select Profile Type: Regular. Enter the required Description. Set Available for Profile Selection: Yes for the intended interactive user.
4. Complete any required catalog values, dates and Business Reason, then Save.
5. Obtain independent approval and refresh Profiles.
6. Expand the approved profile’s linked records. Inspect Domains and Roles. Verify the initial domain relationship before attempting to add a duplicate.
Screen 5Create Profile with its initial domain and selectable settingCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• Profile creation can establish the initial domain association.
• A selectable profile still requires user assignment, effective dates and role grants.
Screen 6Profiles remain separate master recordsCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• Master details describe the profile.
• Domain and role relationships are administered through additional mapping actions.
Expected result
The approved profile is eligible in the intended domain. A user does not receive it merely because it is marked available for selection.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The approved profile is eligible in the intended domain. A user does not receive it merely because it is marked available for selection.,documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-1-3,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-01-04,R1-IAM-01,Identity and Access Management,Set up the access masters and mappings,Module journey,P0,Advanced Configuration → Permission Catalog → Create Permission,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Advanced Configuration → Permission Catalog → Create Permission | 
Who acts | Maker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Maker
Open: Advanced Configuration → Permission Catalog → Create Permission
1. Inspect the existing published permission keys for the target screen and read API. Prefer the matching existing permission when it already exists.
2. For the creation exercise, select Create Permission. Enter a unique Permission key such as DEMO_COUNTRY_READ.
3. Choose the exact offered Registered resource action representing the demo read operation. The illustration uses Country records · READ; use the actual entry in your deployment.
4. Choose Permission effect: ALLOW. Supply the Business Reason and select Submit for Approval.
5. Have the Checker validate the registered action, effect and purpose, then approve. Refresh the Permission Catalog.
6. Before using the new key in a live flow, confirm that the relevant published menu/control requirements reference it, or verify it only as an additional requirement in the isolated demo setup.
Screen 7Create Permission against an existing registered actionCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• The operation must already exist in the resource-action catalog.
• Creating an ALLOW definition does not grant it to any role.
Screen 8Permission Catalog: inspect action, effect and statusCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• The permission key must match the required binding.
• A similarly named permission is not a substitute for an exact published key.
Three different actions: creating a permission defines it; granting it to a role assigns it; adding it as a menu/control requirement constrains access. A new name alone does not satisfy an existing screen’s required permission keys. A DENY definition is not a weaker ALLOW; only use one in a specifically rehearsed policy example.
Expected result
An approved permission definition exists. No user gains access until the appropriate role grants and runtime bindings are effective.
Published permission meanings are immutable in the inspected administration flow. Create a new permission definition or propose a change to a role’s grants instead of silently changing the meaning of a permission already in use.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",An approved permission definition exists. No user gains access until the appropriate role grants and runtime bindings are effective.,documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-1-4,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-01-05,R1-IAM-01,Identity and Access Management,Set up the access masters and mappings,Module journey,P0,Domains → Operations row → More actions → Map profiles,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Domains → Operations row → More actions → Map profiles | 
Who acts | Maker, then Checker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Maker, then Checker
Open: Domains → Operations row → More actions → Map profiles
1. Expand the Operations row first to show the currently linked profiles.
2. If Create Profile already established Operations ↔ Reference data reader, leave that link intact and explain the initial association. To verify an additional change, use a second prepared eligible profile or domain.
3. Select Map profiles or the header’s Domain and profile mappings, then Edit mappings.
4. Choose the source record if it was not carried from the row. Select the intended additional counterpart. Existing links must remain selected unless removal is intended.
5. Select Review changes. Inspect every addition/removal and enter the reason. Select Submit for approval.
6. On the affected record, show the pending Mapping changes. As the independent Checker, inspect the same proposal, approve and confirm.
7. Refresh and expand the domain. Show the resulting profiles. Open Profiles → the profile → Map domains to verify the reverse view.
Screen 9Domain row expanded to show profile relationshipsCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• Eligibility can be viewed from either side.
• A second link demonstrates many-to-many behavior without duplicating the initial association.
Expected result
The approved relationship is visible from both domain and profile views. It does not automatically assign every domain member to the profile.
Access-scope compatibility and protected-record restrictions still apply. Do not change a domain/profile scope merely to force a failed mapping through. Review the stated restriction.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The approved relationship is visible from both domain and profile views. It does not automatically assign every domain member to the profile.,documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-1-5,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-01-06,R1-IAM-01,Identity and Access Management,Set up the access masters and mappings,Module journey,P0,Profiles → Reference data reader row → More actions → Map roles,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Profiles → Reference data reader row → More actions → Map roles | 
Who acts | Maker, then Checker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Maker, then Checker
Open: Profiles → Reference data reader row → More actions → Map roles
1. Open Map roles, or use Profile and role mappings from Profiles or Roles.
2. Keep Reference data reader as the source profile. Select Reference data reader role.
3. Review changes, add a Business Reason and submit for approval.
4. Have the independent Checker inspect the affected row’s proposal and confirm the decision.
5. Refresh and expand the profile: the approved role appears under Roles.
6. Inspect the reverse relationship from Roles → Reference data reader role → Map profiles. Note that additional approved roles can be bundled into a profile and a role can be reused by multiple profiles.
Screen 10Profile relationships: domain eligibility and role bundleCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• The profile’s domains and roles are separate relationships.
• Changing a shared role can affect several profiles and assigned users.
Screen 11Reverse inspection from the Role masterCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• The role remains a master record.
• Linked profiles and menus provide navigation to related access administration.
Expected result
The profile contains the approved role. Runtime privileges still depend on that role’s effective permissions and all applicable conditions.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The profile contains the approved role. Runtime privileges still depend on that role’s effective permissions and all applicable conditions.,documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-1-6,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-01-07,R1-IAM-01,Identity and Access Management,Set up the access masters and mappings,Module journey,P0,Roles → open Reference data reader role → Role Permissions,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Roles → open Reference data reader role → Role Permissions | 
Who acts | Maker, then Checker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Maker, then Checker
Open: Roles → open Reference data reader role → Role Permissions
1. Open the role’s record using its View action. Expand Role Permissions if collapsed.
2. Select Grant permission. Verify the carried role and choose an approved permission from the offered catalog.
3. For the working reader walkthrough, grant the actual registered navigation, screen read, data read and required field/control permissions identified during preparation. A screen may need more than one permission.
4. Add the reason and submit. The permission grant/removal proposal remains attached to its permission row until an independent decision.
5. As Checker, open the same role, inspect the proposed permission row and select its Review/Open proposal action. Read the before/after change. Approve, then Confirm approval.
6. Return as Maker or Business user and refresh the relevant access view. Verify the effective grant.
7. Leave Create, Update, Delete and approval permissions ungranted for this reader example. Rehearse the resulting write denial later.
Item | Walkthrough result | 
Permission definition | Exists and references the correct registered action | 
Role permission grant | Reviewed link to Reference data reader role | 
Profile role link | Reader profile inherits the role | 
User assignment | Only assigned eligible users can select that profile | 
Control/menu requirement | Must match the permission keys actually evaluated at runtime | 
Expected result
The role’s permission rows show the approved read grants. Pending changes do not yet alter effective access.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The role’s permission rows show the approved read grants. Pending changes do not yet alter effective access.,documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-1-7,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-01-08,R1-IAM-01,Identity and Access Management,Set up the access masters and mappings,Module journey,P0,Authorization → Menu Access,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Authorization → Menu Access | 
Who acts | Maker, then Checker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Maker, then Checker
Open: Authorization → Menu Access
1. Open Menu Access. The relationship workspace shows Role and menu access; switch back to it if Menu permission mappings is selected.
2. Select Reference data reader role, then Edit mappings. Locate the registered Country menu.
3. Inspect its action choices. Configure only the intended View/read-related access for the example. Review any automatically included view dependencies.
4. Select Review changes and check the displayed permission/action effects. Add the reason and Submit for approval.
5. Have the independent Checker decide the proposal from the affected row. Refresh to inspect the effective action state.
6. Use Screens & controls to inspect the target screen and its detailed security requirements.
7. Later sign in as the business user with Reference data reader selected. Verify the sidebar is the result of that effective context. Do not infer runtime access from the administrator’s menu alone.
Screen 12Menu Access: role/menu administrationCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• This workspace maintains access to registered navigation entries.
• The role/menu view translates business screen actions into governed access changes.
There is an IAM menu master in the data model. The inspected Menu Access UI is a mapping workspace; it is not an arbitrary new-menu creation form. The effective permission path remains authoritative. A visible menu is not permission to execute every operation on that page.
Expected result
The approved role/menu configuration agrees with the role’s actual permission grants. The user’s authorized navigation reflects the selected effective profile and policy context.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The approved role/menu configuration agrees with the role’s actual permission grants. The user’s authorized navigation reflects the selected effective profile and policy context.,documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-1-8,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-01-09,R1-IAM-01,Identity and Access Management,Set up the access masters and mappings,Module journey,P0,System Access → Screens ; Screen Controls / Fields,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | System Access → Screens ; Screen Controls / Fields | 
Who acts | Authorized Axis administrator | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Authorized Axis administrator
Open: System Access → Screens; Screen Controls / Fields
1. Open Screens and search for the prepared screen. Inspect the screen identity, engine, component/permission counts, source version and mapping state.
2. Open Screen Controls / Fields and locate controls belonging to that screen. Inspect stable identity, kind, path, owning screen and permission binding information.
3. Inspect the difference between a field, action/button, block, menu, view and API control where those kinds are present.
4. Trace one named control back to Menu Access → Screens & controls → Controls & permissions.
5. For a new field, screen, menu or resource action that is not registered, hand the definition to the platform registration/publication process. Re-enter this example after the new definition appears in the appropriate inventory.
Screen 13Axis Screens inventoryCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• The inventory provides the registered presentation identity.
• A mapping state describes mapping/publication work; it does not grant end-user access.
Screen 14Axis Screen Controls / Fields inventoryCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• Control identities connect presentation definitions to IAM requirements.
• The inspected inventory does not offer arbitrary control creation.
Need | Current demo path | 
New business screen or new control | Platform definition/registration/publication, then verify inventory | 
Assign responsibility for an existing screen | Create Screen Mapping and its ownership/review flow | 
Change supported label/visibility/editability/defaults | Experience Version flow, followed by applicable review/publication | 
Grant permission or restrict field access | IAM Role Permissions / Controls & permissions | 
New menu to screen association | IAM-owned registration/publication bridge; verify via Menu Access and inventory | 
Expected result
The authorized user can locate screen and control definitions and knows which administration flow changes ownership, presentation or security.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The authorized user can locate screen and control definitions and knows which administration flow changes ownership, presentation or security.",documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-1-9,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-01-10,R1-IAM-01,Identity and Access Management,Set up the access masters and mappings,Module journey,P0,Permission Catalog → permission row → Map menus; or Menu Access → Menu permission mappings,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Permission Catalog → permission row → Map menus; or Menu Access → Menu permission mappings | 
Who acts | Maker for changes; either authorized operator for inspection | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Maker for changes; either authorized operator for inspection
Open: Permission Catalog → permission row → Map menus; or Menu Access → Menu permission mappings
1. Open the relationship from a permission’s Map menus action, or select Menu permission mappings in Menu Access.
2. Choose the registered menu or permission as the source. Inspect linked entries and their Applies to/Binding information.
3. Distinguish locked Required dependency entries from editable Additional requirement entries. Do not remove baseline dependencies.
4. If using an additional restriction, choose the prepared permission in the isolated demo setup. Review changes, reason and submit; obtain the independent decision.
5. Open Screens & controls, select Country and use Screen information. Identify the menu/screen relationship and applicable registered requirements.
6. Confirm the Axis inventory contains the matching screen and controls. Publication and IAM bridge identity must agree before treating the route as ready.
Screen 15Screen information: connect the menu to its registered screenCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• Inspect the screen and registered security layers.
• This is a verification step, not a claim that a new bridge can be typed into this page.
Expected result
Permission/menu requirements and the registered screen identity are traceable. An additional requirement narrows access; it does not grant that permission to a role.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Permission/menu requirements and the registered screen identity are traceable. An additional requirement narrows access; it does not grant that permission to a role.,documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-1-10,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-01-11,R1-IAM-01,Identity and Access Management,Set up the access masters and mappings,Module journey,P0,Menu Access → Screens & controls → Country → Controls & permissions,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Menu Access → Screens & controls → Country → Controls & permissions | 
Who acts | Maker, then Checker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Maker, then Checker
Open: Menu Access → Screens & controls → Country → Controls & permissions
1. Select the role being inspected. Locate the prepared Country name field/control. Read its Type, Role grant, Field restriction and Additional requirements.
2. Use Edit permission requirements for an editable additional-requirement change. Select only the intended permission, inspect shared-screen impact and submit the proposal.
3. Use the control’s More actions → Grant control permission or Revoke control permission when administering a role grant. This is a different operation from adding a requirement.
4. To verify data-field protection, choose Edit field access for the selected role and field. Pick the offered read-only setting for this example. Use masking only for fields that expose a supported masking option.
5. Review before/after values and submit. Have the independent Checker review and decide the proposal on its corresponding control row.
6. Refresh, then test the actual business user. Verify both rendering behavior and protected-operation enforcement. A disabled field alone is not proof of a backend denial.
Screen 16Controls & permissions: inspect each authorization layerCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• Role grant and additional requirements answer different questions.
• Shared-screen information matters before changing a reused permission.
Screen 17Field access: propose a read-only restrictionCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• Choose a role and registered field.
• The saved proposal requires an eligible decision before becoming effective.
Screen 18Independent review on the originating control rowCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• The reviewer sees the specific control change and before/after values.
• Confirm approval applies to the whole displayed proposal, not unrelated configuration.
Expected result
The approved control requirement, role grant and field rule can each be explained and verified independently. They reference Axis controls through IAM-owned security bindings.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The approved control requirement, role grant and field rule can each be explained and verified independently. They reference Axis controls through IAM-owned security bindings.",documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-1-11,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-01-12,R1-IAM-01,Identity and Access Management,Set up the access masters and mappings,Module journey,P0,Menu Access → Screens & controls → Country → ABAC conditions,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Menu Access → Screens & controls → Country → ABAC conditions | 
Who acts | Maker → Checker → Business user | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Maker → Checker → Business user
Open: Menu Access → Screens & controls → Country → ABAC conditions
1. Use a prepared isolated demo screen/policy, so the condition does not unexpectedly affect other users of a shared screen.
2. Select Add policy. Enter Policy name: Country access in Operations domain.
3. Choose the intended Applies to target. Select Require all conditions for this example.
4. Choose the offered attribute Selected domain, operator is, value Operations. Use the actual offered values, not typed claims about the user.
5. Keep the policy enabled, provide the reason and submit. Have the independent Checker review the before/after condition and approve.
6. Select the Business user’s valid Operations / Reference data reader context. Run the access check and perform the authorized read.
7. For a genuine ABAC-negative walkthrough, use a second approved context that has the same required RBAC read grants but fails this condition. If that comparison context is not prepared, explain the negative case rather than pretending a missing-role denial proves ABAC.
Screen 19ABAC conditions alongside inherited policiesCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• Policies supplement the effective role/permission result.
• Inspect inherited/baseline conditions as well as the edited screen policy.
Screen 20Define a condition using registered runtime attributesCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• Require all conditions means the configured requirements must match.
• Deny when matched has a different meaning and should not be selected for this example.
Expected result
RBAC grants the intended operation and ABAC permits it only in the matching trusted context. A matching condition cannot create a missing role grant.
The role selector in the administration workspace inspects configuration. It does not impersonate a business user. Access check evaluates the signed-in selected context; use the actual user’s session for the final runtime proof.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",RBAC grants the intended operation and ABAC permits it only in the matching trusted context. A matching condition cannot create a missing role grant.,documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-1-12,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-02-01,R1-IAM-02,Identity and Access Management,Create a user as an administrator,Module journey,P0,User Administration → User Accounts → Create user,"Use existing master screens and approved, narrowly scoped demo access. Prepare a maker and a different checker identity, an intended domain/profile and a non-sensitive walkthrough screen. Record the existing grant chain before adding mappings. Do not use one account with two profiles as evidence of independent approval.","Before you act | Required context | 
Screen / entry | User Administration → User Accounts → Create user | 
Who acts | Maker | 
You need | Use existing master screens and approved, narrowly scoped demo access. Prepare a maker and a different checker identity, an intended domain/profile and a non-sensitive walkthrough screen. Record the existing grant chain before adding mappings. Do not use one account with two profiles as evidence of independent approval. | 
Steps and field guidance
Who: Maker
Open: User Administration → User Accounts → Create user
1. Search for the intended User ID and email first so that the demo does not create a duplicate identity.
2. Select Create user. The full-page create form opens with a Back action.
3. Enter the values below. Leave optional dates empty if the account should start immediately and no account-level end date is required. Use a future assignment expiry later to bound this example’s access.
4. Select Save once. Wait for a confirmed receipt and the account workspace. Record the User ID.
5. Read the confirmation: access assignment and approval still follow, and the enrollment email has not been queued yet.
Field | Required? | Demo value / explanation | 
Last Name | Yes | Demo | 
First Name | Yes | Alex | 
Middle Name | No | Leave blank | 
Email Address | Yes | Actual controlled mailbox for the live run | 
User ID | Yes | Unique ID, 3–64 characters starting with a letter | 
User Category | Yes | State in this example; category does not itself grant roles | 
Owner Reference | No | Use a known external owner identifier only when relevant | 
Start Date / End Date | No | Account validity; dates take effect at midnight in the local timezone | 
Account Remarks / Remarks | No | Short business context, without credentials | 
Note | No | Admin-created user walkthrough; approved reference data access only | 
Screen 21User Accounts: start administrative onboardingCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• Create user is the administrator-led entry point.
• Created through distinguishes Admin-created from Self-registered accounts.
Screen 22Complete the administrator’s create formCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• Names, email, User ID and User Category are required.
• The administrator does not enter the new user’s password here.
Expected result
The created account is PENDING. The person/contact details are linked for onboarding. There is no approved profile assignment or enrolled credential merely because Save succeeded.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The created account is PENDING. The person/contact details are linked for onboarding. There is no approved profile assignment or enrolled credential merely because Save succeeded.,documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-2-1,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-02-02,R1-IAM-02,Identity and Access Management,Create a user as an administrator,Module journey,P0,User Accounts → Alex Demo → Progress,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | User Accounts → Alex Demo → Progress | 
Who acts | Maker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Maker
Open: User Accounts → Alex Demo → Progress
1. Open Alex’s account if the create form did not already navigate there. Inspect the header User ID and pending status.
2. Show the six stages: Registration, Personal information, Account activation, Domain and profile, Independent approval and Sign-in readiness.
3. Check why Registration is complete even for an admin-created account: the account has been recorded; Alex did not submit a public registration request.
4. Select Activate account. Review the account name and current status, add an optional note and confirm Activate account.
5. The workspace opens the access-assignment stage. Confirm ACTIVE, then continue to domain/profile assignment.
Screen 23A newly created account still needs activation and accessCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• Completed identity stages are separate from sign-in readiness.
• Use the next action to progress through the same account workspace.
Screen 24Confirm account activationCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• Verify the target account before confirming.
• Activation changes account availability; it does not issue credentials or assign business access.
Expected result
The account becomes ACTIVE. It still needs an effective domain/profile assignment and credential enrollment before sign-in readiness can complete.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The account becomes ACTIVE. It still needs an effective domain/profile assignment and credential enrollment before sign-in readiness can complete.,documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-2-2,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-02-03,R1-IAM-02,Identity and Access Management,Create a user as an administrator,Module journey,P0,Alex Demo → Access assignments → Assign Profile,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Alex Demo → Access assignments → Assign Profile | 
Who acts | Maker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Maker
Open: Alex Demo → Access assignments → Assign Profile
1. Select Assign Profile. The current user should be carried into the form; verify it is Alex.
2. Choose Operations. Choose Reference data reader from the profiles eligible in that domain.
3. Review the inherited role and business-access preview. The intended walkthrough is read-only access to the prepared reference screen.
4. Optionally set Access ends to a future date/time after the demo. This is assignment validity, distinct from account validity.
5. Add the demo note. Select the form’s submission action and wait for its receipt. With the review-required rule, the message should say the proposal was submitted for independent approval.
6. Return to Access assignments. Show the pending proposal on the corresponding row. Current effective access remains unchanged while it is awaiting review.
Screen 25Select the domain and eligible profileCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• Check the account, domain, profile and role preview together.
• Use a future access expiry for the actual meeting.
Screen 26The proposed access remains with its originating accountCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• The pending item can be reviewed from its own access row.
• A recorded proposal is not an effective assignment.
Client Approval Rules can allow automatic application of initial access. If the configured rule allows that and the receipt is APPROVED, explain that the rule applied the assignment automatically; do not claim a human checker approved it. Later assignments and other IAM operations may have different review requirements.
Expected result
The intended assignment is pending under the chosen review-required rule. The user cannot select it as effective access yet, and the initial enrollment email remains dependent on approved access.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The intended assignment is pending under the chosen review-required rule. The user cannot select it as effective access yet, and the initial enrollment email remains dependent on approved access.",documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-2-3,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-02-04,R1-IAM-02,Identity and Access Management,Create a user as an administrator,Module journey,P0,User Accounts → Alex Demo → Access assignments,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | User Accounts → Alex Demo → Access assignments | 
Who acts | Different Checker account | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Different Checker account
Open: User Accounts → Alex Demo → Access assignments
1. Use the checker’s separate signed-in browser. Verify both the person’s account identity and selected checker profile.
2. Find Alex and open Access assignments. Use the row’s Review action or expand the pending row.
3. Compare the before/after values, maker’s reason, domain, profile, inherited role bundle and expiry. Open the account’s Approvals tab if you need the account-filtered request list.
4. Select Approve, add an optional approval note and select Confirm approval in the inline review. On the alternative Approvals detail page the final action is Approve Change.
5. Refresh the account. Confirm the assignment is active/available, the proposal has a completed decision and Sign-in setup shows the enrollment-email state.
6. For a rejection walkthrough, use a separate new proposal and enter a meaningful rejection reason. Rejection must not grant the requested assignment.
Screen 27Review access directly within the account rowCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• The proposed change and decision controls stay with the relevant record.
• The illustration uses a separate checker identity in the isolated fixture.
Screen 28Record the checker’s decisionCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• Approval applies to the exact request and version.
• An approval note helps explain why the requested access is appropriate.
If the action is unavailable | Check | 
Same underlying account submitted the proposal | A different authorized account is required; changing the profile is insufficient. | 
Checker can view but cannot approve | Inspect eligibility, action permission, proposal state and applicable separation-of-duties restrictions. | 
Request already decided or stale | Refresh the record and inspect its latest version; avoid duplicate decisions. | 
Profile is protected or checker is an affected party | Use an eligible authorized reviewer; do not bypass the restriction. | 
Expected result
Approved eligible access is recorded and the enrollment email is queued once. Until the new user enrolls, Sign-in readiness still remains incomplete.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","Approved eligible access is recorded and the enrollment email is queued once. Until the new user enrolls, Sign-in readiness still remains incomplete.",documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-2-4,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-02-05,R1-IAM-02,Identity and Access Management,Create a user as an administrator,Module journey,P0,Alex Demo → Sign-in setup → Refresh account,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Alex Demo → Sign-in setup → Refresh account | 
Who acts | Maker or authorized reader | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Maker or authorized reader
Open: Alex Demo → Sign-in setup → Refresh account
1. Open Sign-in setup after access approval. Read Account status, Sign-in setup and Enrollment email together.
2. Refresh to observe the transport state. Do not treat Queued or Accepted by email provider as proof that Alex has finished enrollment.
3. Have Alex open the newest activation/enrollment message in the real controlled inbox. Check junk/spam if the provider accepted it but it is not visible.
4. Use the actual private link from that message. Do not construct an invitation URL from the account ID.
5. If the invitation has expired or delivery needs a new attempt, use Request Enrollment Email when offered and complete its approved resend workflow. Credential recovery is for accounts that already enrolled.
Screen 29Approved access has queued the enrollment messageCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• The account and assignment are ready for the user’s credential setup.
• Refresh account follows delivery progress.
Screen 30The provider accepted the messageCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• Confirm the message in the actual recipient inbox during the live demo.
• Provider acceptance and completed enrollment are different results.
Displayed state | Meaning / next action | 
Not queued — activate account | Complete account activation first. | 
Not queued — approve access | Assign the profile and finish required access review. | 
Queued / Sending | The delivery service is handling the message; refresh. | 
Accepted by email provider | Transport accepted it; verify the inbox separately. | 
Delivery failed / Delivery canceled | Inspect email, account and access state; use the authorized resend process. | 
Invitation expired | Request a new invitation; use only the latest unexpired link. | 
Verification in progress | The user needs to finish email-code verification. | 
Enrollment complete | The user finished credential enrollment; runtime access checks still apply. | 
Continue with Enroll credentials and complete the first sign-in. The invited user completes the setup; the administrator does not select or distribute that person’s password.
Check before continuing: The approved account shows a traceable enrollment message and its actual delivery stage. The intended person uses the latest eligible invitation; provider acceptance is not proof that it was read.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The approved account shows a traceable enrollment message and its actual delivery stage. The intended person uses the latest eligible invitation; provider acceptance is not proof that it was read.,documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-2-5,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-02-06,R1-IAM-02,Identity and Access Management,Create a user as an administrator,Module journey,P0,Latest activation email → Set Up Your Account → Sign in,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Latest activation email → Set Up Your Account → Sign in | 
Who acts | Applicant | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
User: Applicant
Open: Latest activation email → Set Up Your Account → Sign in
Verify: Finish credential enrollment and enter the approved workspace.
1. Open the newest activation invitation addressed to the applicant. Use the actual invitation supplied by the system; do not construct a URL from an account ID.
2. On Set Up Your Account, choose and confirm a unique password that meets the form’s policy. Do not project or record the password.
3. Select Set Password. Read the current verification code from the applicant’s inbox and enter it on Verify Your Email Code. The verification link and this email code are different stages.
4. Complete enrollment. At Sign in, use the requested username and enrolled credentials, then complete the configured factor.
5. Select an available domain/profile when prompted. Show the active profile in the application header.
6. Open the permitted Country screen or the chosen walkthrough screen. Note that account activation, effective assignment, role grants and policies all still matter.
Screen 31Account activation: choose credentialsCaptured 19 October 2026 · compiled application with illustrative data · click to enlarge
• This is the invitation-led setup screen.
• The illustration contains no usable production invitation or password.
Screen 32Account activation: email-code verificationCaptured 19 October 2026 · compiled application with illustrative data · click to enlarge
• The code is sent to the account’s bound email address.
• Use the latest code and the appropriate resend action if necessary.
Screen 33Native sign-in after enrollmentCaptured 19 October 2026 · compiled application with illustrative data · click to enlarge
• Use the enrolled username and password, then the configured verification step.
• An enabled federated sign-in route can be verified separately.
Expected result
Registration becomes completed/activated, and the user enters an effective approved context. A suspended account, expired assignment or unpermitted screen must still be blocked.
This invitation-led enrollment procedure is also used after an eligible administrator-created account receives its enrollment email. Native enrollment and federated SSO sign-in are separate paths.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","Registration becomes completed/activated, and the user enters an effective approved context. A suspended account, expired assignment or unpermitted screen must still be blocked.",documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-2-6,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-02-07,R1-IAM-02,Identity and Access Management,Create a user as an administrator,Module journey,P0,the portal’s Sign in page,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | the portal’s Sign in page | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
1. Open the portal’s Sign in page. Use the native route if native credentials were enrolled, or the enabled federated provider linked to the account. Complete the verification steps offered by that route.
2. If the workspace selector appears, choose Organization Or Provider, then Access Profile. These are available assignments returned for this user. With a single choice the context may resolve directly.
3. Read the active domain and profile in the header. Open a permitted screen from the dynamic sidebar or authorized search result.
4. To change responsibility, open the top-right profile menu → Switch profile. Select the other offered assignment. Wait for the new context and navigation to load.
5. Before changing a record, confirm the new profile and its permitted actions. Permissions from all assigned profiles are not combined simply because the account can select them.
6. Use the application Back action to return from record pages. A direct bookmark still needs access in the current context.
7. When finished, use the profile menu → Sign out. On a shared machine, close the browser window after sign-out.
What you see | Meaning / next action | 
No available context | Ask an authorized administrator to check account/membership status, approved assignment, domain eligibility, profile selectability and effective dates. | 
Menu list changes after switching | The selected profile has a different effective permission set or context. This is expected. | 
You can see a menu but cannot read the screen | Navigation and protected read requirements must both succeed. Record the exact error and selected context for the administrator. | 
Session expired | Sign in again. If an in-progress submission may have succeeded, inspect the record/proposal receipt before submitting a duplicate. | 
Expected result
The header, available menus and permitted operations agree with the selected effective assignment.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The header, available menus and permitted operations agree with the selected effective assignment.",documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-2-7,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-02-08,R1-IAM-02,Identity and Access Management,Create a user as an administrator,Module journey,P0,Select Operations / Reference data reader → prepared Country screen,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Select Operations / Reference data reader → prepared Country screen | 
Who acts | Business user in a separate browser profile | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Business user in a separate browser profile
Open: Select Operations / Reference data reader → prepared Country screen
1. Show the header’s selected domain/profile and the visible menus. Confirm these belong to the Business user’s actual session.
2. Open Country. Read a known non-sensitive reference record and compare the result with the expected reader permissions.
3. Show that Create/Edit/Delete or approval actions are unavailable when not granted. Where a controlled authorization diagnostic is prepared, also show the server-side deny result. Do not replay a real destructive command for walkthrough.
4. Open the screen-access Access check under the same signed-in context if the user is authorized to use that diagnostic; otherwise have an authorized tester collect the equivalent runtime evidence.
5. Use the prepared ABAC comparison context and show the condition failure while required RBAC grants remain present.
6. Switch back to the intended permitted context and verify the allowed read again.
7. If using revocation, make and approve a separate removal proposal, refresh/renew context as required and verify the revoked operation is denied.
Screen 34Access-check illustration: read allowed, write deniedCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• This screenshot uses isolated example decisions.
• During the live demo, capture the actual user/context and current server result.
Screen 35Access-check illustration: contextual condition denies the actionCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• A policy deny must be distinguished from missing permissions or an expired session.
• Keep the same intended operation and a valid comparison context for a meaningful test.
Check | Expected evidence | 
Dynamic menu | Menu shown or absent under the selected effective profile | 
Allowed read | Actual authorized response and visible record | 
Denied write | Action absent/disabled plus a controlled backend denial where verified | 
ABAC mismatch | Current trusted context fails the intended condition | 
Field restriction | Correct presentation plus enforced data/operation restriction | 
Revoked access | After the effective removal, the former capability is denied | 
Expected result
The demo proves the end-to-end chain instead of stopping at saved configuration or visible navigation.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The demo proves the end-to-end chain instead of stopping at saved configuration or visible navigation.,documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-2-8,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-03-01,R1-IAM-03,Identity and Access Management,Onboard a self-registered user,Module journey,P0,Portal → Sign in → Request an Account,"Use existing master screens and approved, narrowly scoped demo access. Prepare a maker and a different checker identity, an intended domain/profile and a non-sensitive walkthrough screen. Record the existing grant chain before adding mappings. Do not use one account with two profiles as evidence of independent approval.","Before you act | Required context | 
Screen / entry | Portal → Sign in → Request an Account | 
Who acts | Applicant, signed out | 
You need | Use existing master screens and approved, narrowly scoped demo access. Prepare a maker and a different checker identity, an intended domain/profile and a non-sensitive walkthrough screen. Record the existing grant chain before adding mappings. Do not use one account with two profiles as evidence of independent approval. | 
Steps and field guidance
User: Applicant, signed out
Open: Portal → Sign in → Request an Account
Verify: Collect identity/contact information and establish ownership of the email address, without granting access.
1. Open the portal in the applicant’s separate browser profile. Select Request an Account.
2. Enter First Name, optional Middle Name, Last Name, the requested Username and Email Address. Use a real user-controlled inbox for the user walkthrough. Add an optional note explaining the business need.
3. Submit once. Record the confirmation. This is an access request, not an active login.
4. Open the latest verification email in the applicant’s inbox. Follow its link; do not copy its token into slides or the shared demo script.
5. Select Verify Email. Show the Email Verified — Awaiting Approval confirmation. The administrator can now classify the request.
6. Return to Sign in to explain that email verification alone has not created approved access or completed credential setup.
Screen 36Public account request formCaptured 19 October 2026 · compiled application with illustrative data · click to enlarge
• Point to the structured name fields, username and email.
• No domain, profile or administrator role is self-selected on this public form.
• The optional note explains the request; it is not an authorization rule.
Screen 37Submission confirmation and next stepsCaptured 19 October 2026 · compiled application with illustrative data · click to enlarge
• The applicant is directed to the verification email.
• Submitting again is not a substitute for an authorized email resend.
Screen 38Email ownership confirmationCaptured 19 October 2026 · compiled application with illustrative data · click to enlarge
• This page is reached using the latest private verification link.
• No OTP is entered at this particular verification-link step.
Screen 39Verified request awaiting classification and reviewCaptured 19 October 2026 · compiled application with illustrative data · click to enlarge
• Verified email is a prerequisite; it is not approved access.
• Classification, review and credential activation remain distinct.
State / stage | Who acts next | What exists | 
EMAIL_PENDING · Awaiting email verification | Applicant follows the email link | A registration request; access has not been granted. | 
REVIEW_PENDING · Awaiting maker classification | Authorized maker chooses domain/profile | Verified request; no effective new account access. | 
REVIEW_PENDING · Awaiting checker approval | Independent authorized checker | A pending classification proposal; current access is unchanged. | 
APPROVED · Awaiting activation | Applicant opens activation invitation | Approved account/access created and activation mail queued. | 
ACTIVATED · Registration completed | User signs in and selects an available context | Credential enrollment completed; runtime authorization still applies. | 
Expected result
The verified request appears under User Accounts → Registration Requests. The user cannot gain access by requesting a protected profile in the note or changing the URL.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The verified request appears under User Accounts → Registration Requests. The user cannot gain access by requesting a protected profile in the note or changing the URL.,documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-3-1,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-03-02,R1-IAM-03,Identity and Access Management,Onboard a self-registered user,Module journey,P0,User Administration → User Accounts → Registration Requests,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | User Administration → User Accounts → Registration Requests | 
Who acts | Maker, then independent Checker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
User: Maker, then independent Checker
Open: User Administration → User Accounts → Registration Requests
Verify: Choose eligible domain/profile access and review the inherited roles before approval.
1. As Maker, open User Accounts → Registration Requests. Find Alex by username or email. Inspect Workflow Stage and Email Delivery.
2. For a verified, unclassified request select Classify Access. If the request already awaits review, open its existing proposal instead of submitting a duplicate.
3. Choose Operations as Domain and Reference data reader as Profile. The profile must be eligible for that domain. Set Access ends if the demo is time-limited.
4. Inspect Profile Access Preview where available. Inspect the roles and configured business actions, then submit. Use a client approval rule that requires independent review for this scenario.
5. Show the pending status and record the request reference. Do not describe submission as access being granted.
6. Switch to the checker’s browser. Open the matching pending request from its available record review action or Approval Queue. Compare the exact registration, requester, domain, profile, inherited roles and expiry.
7. Approve with a review note, or reject with a meaningful reason. Refresh the source registration record. Approved access should create the account/assignment and queue the activation invitation; rejection must not grant the proposed access.
Screen 40Registration requests within User AccountsCaptured 19 October 2026 · compiled application with illustrative data · click to enlarge
• Workflow Stage identifies whose action is next.
• Email Delivery identifies the message type and transport status.
• Classify Access belongs to an authorized maker.
Screen 41Registration classification formCaptured 19 October 2026 · compiled application with illustrative data · click to enlarge
• Domain and Profile are separate choices.
• Profile eligibility limits the available options.
• The form states when another authorized person must approve.
Screen 42The checker locates the pending registration proposalCaptured 19 October 2026 · compiled application with illustrative data · click to enlarge
• The requester and the intended domain/profile are visible in the pending change.
• The checker uses their own authorized session.
Screen 43Review the exact registration classificationCaptured 19 October 2026 · compiled application with illustrative data · click to enlarge
• Compare domain, profile, effective end date and reason before deciding.
• Approval and rejection controls follow the reviewer’s permissions.
What the checker says and verifies
Review item | Acceptance question | 
Applicant | Is this the intended person and verified email? | 
Domain | Is the business context correct? | 
Profile and roles | Is the requested access proportionate to the stated work? | 
Dates | Is the start/expiry appropriate and in the expected timezone? | 
Independence | Is the reviewer a different authorized account from the requester, with any beneficiary restrictions satisfied? | 
Decision | Does the decision apply only to this exact, current proposal/version? | 
The generic operation identifier APPROVE_SUBSCRIPTION is used for the maker’s classification proposal. It does not mean the maker has independently approved their own request. Also, if the configured Client Approval Rule permits automatic application, the UI may show that path; choose a review-required rule for the example.
Expected result
Pending access remains ineffective until the configured decision is complete. A provider-accepted activation message is not proof that it reached the applicant’s inbox.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Pending access remains ineffective until the configured decision is complete. A provider-accepted activation message is not proof that it reached the applicant’s inbox.,documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-3-2,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-03-03,R1-IAM-03,Identity and Access Management,Onboard a self-registered user,Module journey,P0,Latest activation email → Set Up Your Account → Sign in,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Latest activation email → Set Up Your Account → Sign in | 
Who acts | Applicant | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
User: Applicant
Open: Latest activation email → Set Up Your Account → Sign in
Verify: Finish credential enrollment and enter the approved workspace.
1. Open the newest activation invitation addressed to the applicant. Use the actual invitation supplied by the system; do not construct a URL from an account ID.
2. On Set Up Your Account, choose and confirm a unique password that meets the form’s policy. Do not project or record the password.
3. Select Set Password. Read the current verification code from the applicant’s inbox and enter it on Verify Your Email Code. The verification link and this email code are different stages.
4. Complete enrollment. At Sign in, use the requested username and enrolled credentials, then complete the configured factor.
5. Select an available domain/profile when prompted. Show the active profile in the application header.
6. Open the permitted Country screen or the chosen walkthrough screen. Note that account activation, effective assignment, role grants and policies all still matter.
Screen 44Account activation: choose credentialsCaptured 19 October 2026 · compiled application with illustrative data · click to enlarge
• This is the invitation-led setup screen.
• The illustration contains no usable production invitation or password.
Screen 45Account activation: email-code verificationCaptured 19 October 2026 · compiled application with illustrative data · click to enlarge
• The code is sent to the account’s bound email address.
• Use the latest code and the appropriate resend action if necessary.
Screen 46Native sign-in after enrollmentCaptured 19 October 2026 · compiled application with illustrative data · click to enlarge
• Use the enrolled username and password, then the configured verification step.
• An enabled federated sign-in route can be verified separately.
Expected result
Registration becomes completed/activated, and the user enters an effective approved context. A suspended account, expired assignment or unpermitted screen must still be blocked.
This invitation-led enrollment procedure is also used after an eligible administrator-created account receives its enrollment email. Native enrollment and federated SSO sign-in are separate paths.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","Registration becomes completed/activated, and the user enters an effective approved context. A suspended account, expired assignment or unpermitted screen must still be blocked.",documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-3-3,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-03-04,R1-IAM-03,Identity and Access Management,Onboard a self-registered user,Module journey,P0,the portal’s Sign in page,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | the portal’s Sign in page | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
1. Open the portal’s Sign in page. Use the native route if native credentials were enrolled, or the enabled federated provider linked to the account. Complete the verification steps offered by that route.
2. If the workspace selector appears, choose Organization Or Provider, then Access Profile. These are available assignments returned for this user. With a single choice the context may resolve directly.
3. Read the active domain and profile in the header. Open a permitted screen from the dynamic sidebar or authorized search result.
4. To change responsibility, open the top-right profile menu → Switch profile. Select the other offered assignment. Wait for the new context and navigation to load.
5. Before changing a record, confirm the new profile and its permitted actions. Permissions from all assigned profiles are not combined simply because the account can select them.
6. Use the application Back action to return from record pages. A direct bookmark still needs access in the current context.
7. When finished, use the profile menu → Sign out. On a shared machine, close the browser window after sign-out.
What you see | Meaning / next action | 
No available context | Ask an authorized administrator to check account/membership status, approved assignment, domain eligibility, profile selectability and effective dates. | 
Menu list changes after switching | The selected profile has a different effective permission set or context. This is expected. | 
You can see a menu but cannot read the screen | Navigation and protected read requirements must both succeed. Record the exact error and selected context for the administrator. | 
Session expired | Sign in again. If an in-progress submission may have succeeded, inspect the record/proposal receipt before submitting a duplicate. | 
Expected result
The header, available menus and permitted operations agree with the selected effective assignment.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The header, available menus and permitted operations agree with the selected effective assignment.",documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-3-4,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-03-05,R1-IAM-03,Identity and Access Management,Onboard a self-registered user,Module journey,P0,Select Operations / Reference data reader → prepared Country screen,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Select Operations / Reference data reader → prepared Country screen | 
Who acts | Business user in a separate browser profile | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Business user in a separate browser profile
Open: Select Operations / Reference data reader → prepared Country screen
1. Show the header’s selected domain/profile and the visible menus. Confirm these belong to the Business user’s actual session.
2. Open Country. Read a known non-sensitive reference record and compare the result with the expected reader permissions.
3. Show that Create/Edit/Delete or approval actions are unavailable when not granted. Where a controlled authorization diagnostic is prepared, also show the server-side deny result. Do not replay a real destructive command for walkthrough.
4. Open the screen-access Access check under the same signed-in context if the user is authorized to use that diagnostic; otherwise have an authorized tester collect the equivalent runtime evidence.
5. Use the prepared ABAC comparison context and show the condition failure while required RBAC grants remain present.
6. Switch back to the intended permitted context and verify the allowed read again.
7. If using revocation, make and approve a separate removal proposal, refresh/renew context as required and verify the revoked operation is denied.
Screen 47Access-check illustration: read allowed, write deniedCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• This screenshot uses isolated example decisions.
• During the live demo, capture the actual user/context and current server result.
Screen 48Access-check illustration: contextual condition denies the actionCaptured 20 October 2026 · compiled application with illustrative data · click to enlarge
• A policy deny must be distinguished from missing permissions or an expired session.
• Keep the same intended operation and a valid comparison context for a meaningful test.
Check | Expected evidence | 
Dynamic menu | Menu shown or absent under the selected effective profile | 
Allowed read | Actual authorized response and visible record | 
Denied write | Action absent/disabled plus a controlled backend denial where verified | 
ABAC mismatch | Current trusted context fails the intended condition | 
Field restriction | Correct presentation plus enforced data/operation restriction | 
Revoked access | After the effective removal, the former capability is denied | 
Expected result
The demo proves the end-to-end chain instead of stopping at saved configuration or visible navigation.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The demo proves the end-to-end chain instead of stopping at saved configuration or visible navigation.,documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-3-5,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-04-01,R1-IAM-04,Identity and Access Management,Operate and govern existing access,Module journey,P0,"Verify sensitive actions, change credentials and recover access","Use existing master screens and approved, narrowly scoped demo access. Prepare a maker and a different checker identity, an intended domain/profile and a non-sensitive walkthrough screen. Record the existing grant chain before adding mappings. Do not use one account with two profiles as evidence of independent approval.","Before you act | Required context | 
Screen / entry | Verify sensitive actions, change credentials and recover access | 
Who acts | Authorized administrator / reviewer | 
You need | Use existing master screens and approved, narrowly scoped demo access. Prepare a maker and a different checker identity, an intended domain/profile and a non-sensitive walkthrough screen. Record the existing grant chain before adding mappings. Do not use one account with two profiles as evidence of independent approval. | 
Steps and field guidance
1. Choose the task that matches the problem: verify a sensitive action, replace native credentials, recover an account or recover at the external identity provider.
2. Start from the screen named in the table below and complete the required current identity verification.
3. Follow only that task’s setup, confirmation or independent-review path. Use the latest eligible code/invitation and inspect its outcome before requesting another.
4. Sign in through the resulting supported path and check the selected domain/profile. If you cancel, return to the workspace and confirm that no incomplete replacement is being treated as completed.
Task | Steps | Successful checkpoint | 
Verify sensitive actions | Profile menu → Verify sensitive actions. Complete the current trusted verification flow and return to the requested workspace action. | The protected action rechecks the session’s current assurance. A successful normal login alone may be insufficient. | 
Change native credentials | Profile menu → Change credentials. This routes through sensitive-action verification before replacement setup. Follow the offered setup and email-confirmation steps. | Use the replacement credentials on a new sign-in; confirm the stated session effects. | 
Leave the verification/replacement flow | Use the page’s offered return/cancel action. If the session is no longer usable, return through the portal sign-in and select your assignment. | The user can resume permitted work without assuming an incomplete credential replacement succeeded. | 
Administrative recovery | Both administrators verify sensitive actions. The maker opens Credential Recovery or the account’s Sign-in setup recovery action, selects the account, records Identity verification performed and the Business Reason, and submits for independent review. | Approval immediately revokes old credentials and sessions. Only the approving reviewer can use Issue Recovery Invitation. They deliver the short-lived, one-use link privately to the verified person. Issuing another link invalidates the previous one. | 
Expired invitation or code | Use the supported resend/request-enrollment action after checking eligibility and the latest delivery status. Use the newest invitation/code. | Enrollment completes once; an old link is not treated as evidence of access. | 
Federated password problem | Use the configured identity provider’s account-recovery process; ask an authorized administrator to check the internal identity link if sign-in cannot resolve the account. | External authentication and internal IAM assignment both succeed. | 
Do not put passwords, OTPs, recovery links or invitation tokens in the shared demo evidence. Recovery is not a way to create a new role grant. If a flow returns DB_EXEC_ERROR, preserve its correlation ID and check whether a request already exists before retrying.
Check before continuing: The selected credential or recovery path completes its required verification and confirmation. A subsequent authorized sign-in succeeds; no new role grant is inferred from credential recovery.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The selected credential or recovery path completes its required verification and confirmation. A subsequent authorized sign-in succeeds; no new role grant is inferred from credential recovery.,documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-4-1,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-04-02,R1-IAM-04,Identity and Access Management,Operate and govern existing access,Module journey,P0,the intended test or business account and inspect current status and effective assignments.,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | the intended test or business account and inspect current status and effective assignments. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
1. Open the intended test or business account and inspect current status and effective assignments.
2. Select the needed lifecycle action from the table below. Check whether it affects an assignment, the account or existing sessions.
3. Record the business reason and obtain the independent decision when required. Preserve the original account and assignment references.
4. Reopen the account and verify the effective result from the affected user context. Restoration must not recreate an expired or revoked grant.
Scenario | Procedure | Checkpoint | 
Add a second business profile | Maker proposes another eligible assignment; a different checker completes required review. | The existing assignment remains unchanged while the new request is pending. After approval, the user can choose the new available context. | 
Reject an inappropriate request | Submit a separate prepared proposal; checker rejects with a reason. | The proposed access does not become effective. | 
Revoke an assignment | From the permitted assignment action, propose revocation with a reason and complete required review. | After application, refresh/reselect context and verify that revoked assignment is unusable. | 
Suspend the demo account | An authorized lifecycle operator opens Sign-in setup and selects Suspend Account with a reason. | The UI states existing sessions are revoked immediately; verify the actual browser/session outcome. | 
Restore, when eligible | Use Restore account with the permitted operator. | Restoration does not recreate an expired/revoked assignment or eliminate ordinary authorization checks. | 
End the walkthrough | Use approved expiry/revocation/suspension appropriate for this example user; preserve audit history. | Do not hard-delete records or close a reusable demo account. Closure is terminal. | 
Use only the newly prepared demo account for these operations. Do not suspend the operator or checker account. Verify the action on the UI and verify the resulting state; a status badge alone is insufficient evidence that an old session has stopped working.
Check before continuing: The requested assignment/account change is reflected in the effective user context and session behavior. Original requests, decisions and history remain available.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The requested assignment/account change is reflected in the effective user context and session behavior. Original requests, decisions and history remain available.",documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-4-2,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-04-03,R1-IAM-04,Identity and Access Management,Operate and govern existing access,Module journey,P0,Administer client approval rules,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Administer client approval rules | 
Who acts | Authorized administrator / reviewer | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Open Access Governance → Client Approval Rules. The screen shows Workflow, Approval Flow, Version and Managed By. These settings govern eligible initial onboarding submissions; they are not a global switch to bypass later access review.
1. Inspect the current workflow row and effective version before planning the walkthrough.
2. For an authorized configuration change, open the row and choose Checker Required or Automatic Approval. Supply a Policy Code when the form requests a new policy.
3. Select Submit Policy. Read the notice: the policy change itself is submitted for independent approval and the current setting remains effective until that decision.
4. Have a different eligible reviewer inspect the policy proposal. Refresh the rule after the confirmed decision.
5. Use a new, explicitly prepared onboarding submission to verify the effective setting. Inspect the specific proposal’s policy/receipt; do not infer that old pending requests changed automatically.
6. Use Submit Retirement only when retirement is the intended configuration change and its downstream behavior has been reviewed.
Expected result
The operator can explain which onboarding rule applies, which policy version is effective and why later access changes still require their own checks.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The operator can explain which onboarding rule applies, which policy version is effective and why later access changes still require their own checks.",documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-4-3,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-04-04,R1-IAM-04,Identity and Access Management,Operate and govern existing access,Module journey,P0,"the record, enter edit mode when authorized and set Enabled plus the intended start/end values","Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | the record, enter edit mode when authorized and set Enabled plus the intended start/end values | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Open Advanced Configuration → Menu Schedules. This controls the availability of a registered menu. It is separate from the Enterprise Scheduler that executes business jobs.
1. Find the prepared demo menu and inspect its availability: Always Available, Disabled, Scheduled, Available or Ended.
2. Open the record, enter edit mode when authorized and set Enabled plus the intended start/end values. Use a non-critical walkthrough menu.
3. Review the exact change and submit the proposal with a reason. Complete the independent review from its record or the eligible queue.
4. Recheck the row after the decision. Under the affected user context, verify the menu and protected screen behavior inside/outside the approved window.
5. Restore the intended window through the permitted workflow after the walkthrough.
Expected result
Availability constrains an otherwise authorized menu. Making a menu available does not grant a missing permission.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Availability constrains an otherwise authorized menu. Making a menu available does not grant a missing permission.,documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-4-4,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-04-05,R1-IAM-04,Identity and Access Management,Operate and govern existing access,Module journey,P0,Configure and verify federated sign-in,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Configure and verify federated sign-in | 
Who acts | Authorized administrator / reviewer | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Use User Administration → SSO Providers and SSO Identities with a prepared non-production walkthrough identity or an approved existing provider.
Provider / identity field | What the administrator supplies | 
Provider Code / Provider Name | A unique reference and recognizable provider name. | 
Issuer URL | The configured identity provider’s exact issuer. | 
Application Client ID | The registered application identifier. | 
Secret Reference | The configured secret reference, not a secret pasted into demo notes. | 
Identity Claim | The supported claim offered by the provider configuration. | 
SSO Provider + User Account | The provider and intended internal identity to link. | 
External Subject or Entra Object ID | The verified provider-issued stable subject expected by the configured claim; an arbitrary email address is not a replacement. | 
1. Verify the provider-side application, callback configuration and secret reference with the identity administrator before the client session.
2. Create or inspect the provider from SSO Providers. Submit any changes through the offered governed action; obtain the required independent decision.
3. From SSO Identities, propose the provider-to-account link using the verified external subject. Review the exact account and subject before approval.
4. In the business user’s separate browser, select the enabled provider on Sign in and authenticate at that provider.
5. After return, select the permitted internal domain/profile. Verify its menus and a protected read operation.
6. For a lifecycle walkthrough, inspect the offered disable-provider or revoke-identity action and its scope. Do not disable the only working operator login during this task.
Expected result
The provider establishes identity; the internal account, membership, effective profile assignment and IAM policies still determine access.
The UI has provider creation, identity linking and governed disable/revoke operations. This guide does not assume that a particular provider is already configured, or that a disabled provider has a one-click re-enable action on every screen. Review its current configuration and available action before the demo.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The provider establishes identity; the internal account, membership, effective profile assignment and IAM policies still determine access.",documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-4-5,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-04-06,R1-IAM-04,Identity and Access Management,Operate and govern existing access,Module journey,P0,Delegate access for a bounded period,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Delegate access for a bounded period | 
Who acts | Authorized administrator / reviewer | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Open Access Governance → Delegations.
1. Select Delegate Access when authorized. Choose the eligible Source assignment, Recipient user and Delegation ends time.
2. Check that the source responsibility and recipient are appropriate. Add a Business Reason and submit.
3. A different eligible reviewer inspects the source, recipient, dates and effect, then decides the proposal.
4. Inspect the resulting delegation and verify the recipient’s effective context through the normal sign-in/access checks.
5. Use End Delegation when the temporary duty ends, complete required review and verify the former delegated access is no longer usable.
Expected result
The delegation remains bound to its source, permitted scope and expiry. It is not a permanent copy of an administrator’s privileges.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The delegation remains bound to its source, permitted scope and expiry. It is not a permanent copy of an administrator’s privileges.",documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-4-6,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-04-07,R1-IAM-04,Identity and Access Management,Operate and govern existing access,Module journey,P0,Separation of Duties and define the intended domain and conflicting role pair through Separate Duties,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Separation of Duties and define the intended domain and conflicting role pair through Separate Duties | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
1. Open Separation of Duties and define the intended domain and conflicting role pair through Separate Duties. Record the policy code and reason, submit and obtain the independent decision.
2. Use the normal access-request flow on a prepared UAT account to check that the conflicting combination is rejected. Preserve its denial reference.
3. If an approved business exception is needed, open Timed Exceptions and request the exact policy/user pairing with an explicit end and reason. Obtain the required review.
4. Verify only the scoped approved exception, then revoke it or verify its expiry. Confirm that the ordinary conflict restriction applies again.
Task | Operating steps | 
Define a conflict | Separation of Duties → Separate Duties. Supply Policy code, Domain, First role, Conflicting role and reason. Submit and complete the independent decision. | 
Verify enforcement | Use a prepared test account and conflicting assignment through the normal access workflow. Record the actual conflict/deny response and leave current permitted access intact. | 
Request an exception | Timed Exceptions → Request Timed Exception. Select the exact Policy and User Account, set Exception ends, explain the need and submit for the required review. | 
Verify an approved exception | Check its scope and dates, then rehearse the intended operation under that user’s actual context. Other grants and policy checks still apply. | 
End the exception or policy | Use Revoke Timed Exception or Retire Duties Policy only for the intended record, with the required reason and decision. Confirm the resulting effective restriction. | 
Use an isolated prepared business conflict. An exception does not disable all duty controls, and changing profiles does not make a maker independent from their own proposal.
Check before continuing: The defined conflicting role combination is denied unless the exact reviewed, unexpired exception applies. Ending the exception restores the ordinary restriction.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The defined conflicting role combination is denied unless the exact reviewed, unexpired exception applies. Ending the exception restores the ordinary restriction.",documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-4-7,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-04-08,R1-IAM-04,Identity and Access Management,Operate and govern existing access,Module journey,P0,"Access Review and supply Campaign code, Campaign name, Domain, Assigned reviewer and Review due, plus the Business Reason.","Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Access Review and supply Campaign code, Campaign name, Domain, Assigned reviewer and Review due, plus the Business Reason. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Use Access Governance → Access Reviews for campaigns and My Review Items for the assigned reviewer’s work.
1. Open Access Review and supply Campaign code, Campaign name, Domain, Assigned reviewer and Review due, plus the Business Reason.
2. Submit the campaign action and follow its governance receipt. Inspect the resulting campaign and assigned review items.
3. As the assigned authorized reviewer, open My Review Items. Inspect the user, assignment, domain/profile and current need for access.
4. For an item that remains justified, choose Retain Reviewed Access with the reason. For an item that should end, choose Remove Reviewed Access and follow the required decision/application flow.
5. Refresh the item and verify the effective result. A submitted removal proposal alone does not establish that access ended.
6. Return to the campaign, resolve outstanding items and use Close Access Review when offered. Retain the evidence of each decision.
Expected result
The campaign has identifiable reviewed items and outcomes. Creation of a campaign is not completion of the review.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The campaign has identifiable reviewed items and outcomes. Creation of a campaign is not completion of the review.,documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-4-8,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-04-09,R1-IAM-04,Identity and Access Management,Operate and govern existing access,Module journey,P0,Use just-in-time and emergency access,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Use just-in-time and emergency access | 
Who acts | Authorized administrator / reviewer | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
1. Verify sensitive actions, then open Access Governance → Privileged Access. Choose either Just-In-Time with independent approval or Emergency with existing pre-approved eligibility.
2. Select the eligible permission and permitted duration, record the business reason and submit the chosen request.
3. For JIT, obtain a different eligible reviewer’s decision and use Activate when permitted. For Emergency, follow the state and action returned for the approved eligibility.
4. Perform only the authorized operation and inspect Recorded Activity. Revoke or verify expiry, then complete eligible post-use review and closure.
Open Access Governance → Privileged Access. These operations require the appropriate permissions and current trusted step-up where indicated. Verify only an eligible permission prepared for the session.
Stage | Just-in-time path | Emergency path | 
Prepare | Use Verify sensitive actions; confirm an eligible permission exists in the selected profile. | An authorized administrator first governs Emergency Eligibility for the user, assigned profile, permission, eligibility end and maximum duration. | 
Request | Request temporary access → Just-In-Time · Independent Approval. Choose Permission, duration and Business Reason. | Request temporary access → Emergency · Pre-Approved Eligibility. Choose eligible Permission, matching approved eligibility, Emergency category, duration and reason. | 
Decision and activation | A different eligible reviewer approves; the owner then uses Activate. Both protected transitions recheck required assurance. | Follow the returned state and offered action under the pre-approved eligibility. Do not treat Emergency as unrestricted access. | 
Use and monitor | Perform the permitted walkthrough operation and inspect Recorded Activity. | Inspect the same activity/expiry evidence within the emergency grant’s limits. | 
End | Use Revoke Now, or verify expiry. Cancel a not-yet-active request when appropriate. | Revoke/expire the temporary grant; separately revoke eligibility if its future use should end. | 
Review and close | Eligible reviewer uses Review Usage after the grant ends, records findings and then Close Request when offered. | The same post-use review and closure controls remain important. | 
The inspected form caps a JIT request at 30 minutes and an emergency request at 15 minutes; server eligibility/policy can further constrain duration. Requested, Approved and Active are distinct states. The activity panel shows the latest 50 decisions, not the entire audit store.
Expected result
The permission is usable only for its authorized context and bounded lifetime, with accountable approval or pre-approved emergency eligibility and post-use evidence.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The permission is usable only for its authorized context and bounded lifetime, with accountable approval or pre-approved emergency eligibility and post-use evidence.",documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-4-9,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-04-10,R1-IAM-04,Identity and Access Management,Operate and govern existing access,Module journey,P0,a row for details,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | a row for details | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Screen | Use | 
Sign-In History | Inspect authentication outcomes and stages for the relevant user/time range. | 
Failed Sign-In Attempts | Investigate failed attempts within authorized scope; a deliberate demo failure must use a prepared test account. | 
Active Sessions | Inspect unexpired, unrevoked sessions and their last selected domain/profile/activity. | 
Session History | Inspect session lifecycle and ended-session evidence. | 
Security Dashboard | Open the reviewed/published security dashboard configuration if available to this profile; its configuration availability is separate from raw report permissions. | 
1. Choose the report, search the walkthrough User ID and submit Search.
2. Use both start/end dates, or leave both blank for the default last-seven-day range. The inspected report validates ranges of up to 90 days.
3. Inspect status, authentication stage or session domain/profile, and the report’s Updated time. Active means unexpired/unrevoked; it does not prove the person is presently at the keyboard.
4. Use Refresh for an immediate reload. The offered auto-refresh interval is five minutes while the page is visible.
5. Open a row for details. Export Data on these security-report screens exports the currently loaded page, which is up to 50 records. Do not call that export the complete audit history.
6. Compare the actual session result after sign-out, suspension or revocation when those are verified.
Expected result
The authorized user can distinguish authentication success, effective authorization, current session validity and historical evidence.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The authorized user can distinguish authentication success, effective authorization, current session validity and historical evidence.",documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-4-10,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-04-11,R1-IAM-04,Identity and Access Management,Operate and govern existing access,Module journey,P0,Alex Demo → Audit details; Approvals; Access hierarchy; sign-in reports,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Alex Demo → Audit details; Approvals; Access hierarchy; sign-in reports | 
Who acts | Authorized administrator / auditor | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Authorized administrator / auditor
Open: Alex Demo → Audit details; Approvals; Access hierarchy; sign-in reports
Evidence | Where to verify it | What to explain | 
Account identity and source | User Accounts and Account information | User ID, Admin-created source, account status and effective dates. | 
Person/contact information | Personal information | The linked person and contact details used during onboarding; ownership is distinct from permission grants. | 
Creation / update metadata | Account → Audit details | Creation/update information available for the record. Do not describe these fields as an exhaustive event ledger. | 
Access decision | Account → Approvals and originating access row | Requester, exact proposed values, decision, reviewer and reason; pending versus applied. | 
Effective access chain | Account → Access hierarchy | Assigned domain/profile and inherited role/permission chain. | 
Credential enrollment / delivery | Account → Sign-in setup | Enrollment and invitation/delivery status; avoid displaying tokens. | 
Authentication results | Reports → Sign-In History / Failed Sign-In Attempts | Successful sign-in and any deliberate failed attempt within the approved demo scope. | 
Session lifecycle | Reports → Active Sessions / Session History | Current session and, when exercised, its end/revocation. | 
1. Record the User ID, assignment/proposal reference, tenant/domain/profile, decision timestamp and reviewer for this example evidence.
2. Filter the available reports to the demo account and the meeting time range. Show only the evidence needed for this user.
3. Compare the effective access now with the originally requested assignment. Verify the intended expiry.
4. If a report or audit event is unavailable, record that gap explicitly. Do not claim that a record’s Created On field proves every authentication or authorization event.
Expected result
The authorized user can trace who created the account, who proposed and approved the business access, whether enrollment completed and which sign-in/session evidence is actually available.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The authorized user can trace who created the account, who proposed and approved the business access, whether enrollment completed and which sign-in/session evidence is actually available.",documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-4-11,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-04-12,R1-IAM-04,Identity and Access Management,Operate and govern existing access,Module journey,P0,"the header notification bell and read the item’s subject, stage and available action","Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | the header notification bell and read the item’s subject, stage and available action | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
1. Open the header notification bell and read the item’s subject, stage and available action. Mark as read only changes its read state; it does not approve a request.
2. When an Open/action link is offered, follow it using the account that received the notification and the profile responsible for that work.
3. For an email link, sign in through the supported flow if requested. The application rechecks account, profile and work-item access before opening it.
4. If Notification unavailable appears, use Try again after checking the context, Switch profile if you have the required assignment, or Open notifications.
5. If the message contains only a reference, open the originating account/master and locate its pending change. Use Approval Queue as the alternative authorized entry.
6. Make the decision only after opening and inspecting the current proposal. Do not assume an email’s status is still current.
Expected result
The notification leads to an authorized work item; possession of a link or token does not grant permission to decide it.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The notification leads to an authorized work item; possession of a link or token does not grant permission to decide it.,documentation/KERNEL_DOCUMENTATION_HUB.html#iam-demo/step-4-12,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-EX-01,R1-IAM-05,Identity and Access Management,Exception / recovery,Exception / recovery,P0,Menu missing,"Use existing master screens and approved, narrowly scoped demo access. Prepare a maker and a different checker identity, an intended domain/profile and a non-sensitive walkthrough screen. Record the existing grant chain before adding mappings. Do not use one account with two profiles as evidence of independent approval.","1. Prepare a disposable record exhibiting this condition: Menu missing.
2. Check selected profile role closure, menu linkage, active/effective mappings and screen bridge.
3. Reopen the affected record and its history; verify: Do not insert a static sidebar item to hide an authorization gap.
4. Record actual outcome and supporting record/version or denial evidence.",Do not insert a static sidebar item to hide an authorization gap.,documentation/KERNEL_DOCUMENTATION_HUB.html#iam-manual/decision-guide,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-EX-02,R1-IAM-05,Identity and Access Management,Exception / recovery,Exception / recovery,P0,Menu visible but 403 on the screen,"Use existing master screens and approved, narrowly scoped demo access. Prepare a maker and a different checker identity, an intended domain/profile and a non-sensitive walkthrough screen. Record the existing grant chain before adding mappings. Do not use one account with two profiles as evidence of independent approval.","1. Prepare a disposable record exhibiting this condition: Menu visible but 403 on the screen.
2. Check screen-read permission and current ABAC context.
3. Reopen the affected record and its history; verify: Menu visibility is not proof that the read endpoint is authorized.
4. Record actual outcome and supporting record/version or denial evidence.",Menu visibility is not proof that the read endpoint is authorized.,documentation/KERNEL_DOCUMENTATION_HUB.html#iam-manual/decision-guide,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-EX-03,R1-IAM-05,Identity and Access Management,Exception / recovery,Exception / recovery,P0,Checker sees pending row but no approve action,"Use existing master screens and approved, narrowly scoped demo access. Prepare a maker and a different checker identity, an intended domain/profile and a non-sensitive walkthrough screen. Record the existing grant chain before adding mappings. Do not use one account with two profiles as evidence of independent approval.","1. Prepare a disposable record exhibiting this condition: Checker sees pending row but no approve action.
2. Check exact action grant, assignment, record state, subject separation and freshness.
3. Reopen the affected record and its history; verify: Switching profile does not change the submitting subject identity.
4. Record actual outcome and supporting record/version or denial evidence.",Switching profile does not change the submitting subject identity.,documentation/KERNEL_DOCUMENTATION_HUB.html#iam-manual/decision-guide,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-EX-04,R1-IAM-05,Identity and Access Management,Exception / recovery,Exception / recovery,P0,Field visible but read-only,"Use existing master screens and approved, narrowly scoped demo access. Prepare a maker and a different checker identity, an intended domain/profile and a non-sensitive walkthrough screen. Record the existing grant chain before adding mappings. Do not use one account with two profiles as evidence of independent approval.","1. Prepare a disposable record exhibiting this condition: Field visible but read-only.
2. Inspect control permission and field policy.
3. Reopen the affected record and its history; verify: A display format change in Axis will not grant update authority.
4. Record actual outcome and supporting record/version or denial evidence.",A display format change in Axis will not grant update authority.,documentation/KERNEL_DOCUMENTATION_HUB.html#iam-manual/decision-guide,R1-G01; R1-G12,Not run,,,,,,,Not run,
IAM-EX-05,R1-IAM-05,Identity and Access Management,Exception / recovery,Exception / recovery,P0,500 DB_EXEC_ERROR,"Use existing master screens and approved, narrowly scoped demo access. Prepare a maker and a different checker identity, an intended domain/profile and a non-sensitive walkthrough screen. Record the existing grant chain before adding mappings. Do not use one account with two profiles as evidence of independent approval.","1. Prepare a disposable record exhibiting this condition: 500 DB_EXEC_ERROR.
2. Record route, timestamp and correlation; inspect server-side failure.
3. Reopen the affected record and its history; verify: A database execution failure is not fixed by repeatedly broadening permissions.
4. Record actual outcome and supporting record/version or denial evidence.",A database execution failure is not fixed by repeatedly broadening permissions.,documentation/KERNEL_DOCUMENTATION_HUB.html#iam-manual/decision-guide,R1-G01; R1-G12,Not run,,,,,,,Not run,
PULSE-01-01,R1-PULSE-01,Pulse,Prepare the source and reviewed datasets,Module journey,P1,Vista → Sources & datasets → Available Datasets → Connections → New connection,Use a published authorized dataset with a stable key and a controlled fictional record such as CASE1001. Prepare related rows if the template uses repeats. Select a maker and independent checker. For output-only demonstrations use clearly fictional addresses; for actual sending use an authorized controlled recipient and configured live transport.,"Before you act | Required context | 
Screen / entry | Vista → Sources & datasets → Available Datasets → Connections → New connection | 
Who acts | Maker | 
You need | Use a published authorized dataset with a stable key and a controlled fictional record such as CASE1001. Prepare related rows if the template uses repeats. Select a maker and independent checker. For output-only demonstrations use clearly fictional addresses; for actual sending use an authorized controlled recipient and configured live transport. | 
Steps and field guidance
Who: Maker
Open: Vista → Sources & datasets → Available Datasets → Connections → New connection
1. Enter Connection name and Connection code. Choose the approved HTTPS endpoint that returns your synthetic records as JSON. Do not copy an old screenshot endpoint as an environment configuration.
2. Choose authentication: Public API, Bearer token reference, API key header reference, or Username and password reference. Enter only the configured private credential reference; for an API key, also specify the header name.
3. Set JSON row path to the array location, for example data.records. Leave it blank for a root JSON array.
4. Set Maximum response rows and Timeout in seconds. For this small demo, 100 rows and 15 seconds are sufficient when allowed.
5. For synthetic public reference data choose the corresponding Row scope. For tenant-specific business data choose tenant matching and the actual Tenant ID field. Do not use public scope to bypass tenant filtering.
6. Expand Data access policy when your administrator has supplied the registered resource/permission requirements.
7. Select Save connection draft. On its grid row select Test & discover. If queued, use Check test result until it reaches a usable READY result. Inspect discovered fields, types, row count and the latest snapshot.
Screen 1Connection definition and authentication referencesExisting application recorded test · example records may differ from your tenant · click to enlarge
• The external endpoint and credential reference belong to the connection.
• The screenshot uses an earlier test API; use your approved demo endpoint.
Expected result
The connection draft has a successful field-discovery result for its current revision. Failure, timeout or an empty field contract is shown explicitly.
This self-service flow is an approved-host HTTPS JSON connector. The inspected UI supports a maximum of 500 response rows and 2 MB, with 1–30 second timeouts. It uses an explicit source snapshot. It is not an arbitrary SQL connection browser or a promise of unlimited provider/pagination support.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The connection draft has a successful field-discovery result for its current revision. Failure, timeout or an empty field contract is shown explicitly.",documentation/KERNEL_DOCUMENTATION_HUB.html#pulse-demo/step-1-1,R1-G04; R1-G06,Not run,,,,,,,Not run,
PULSE-01-02,R1-PULSE-01,Pulse,Prepare the source and reviewed datasets,Module journey,P1,Connections → the same record row,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Connections → the same record row | 
Who acts | Maker → independent Checker → authorized Publisher | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Maker → independent Checker → authorized Publisher
Open: Connections → the same record row
1. Maker completes Test & discover for the saved revision, then selects Submit for review. Provide a meaningful reason.
2. Checker opens the same connection, inspects endpoint, authentication reference, tenant scope and selected fields, then runs its own Test & discover.
3. After its current successful test, Checker chooses Approve or Return on the row. Returned changes go back to the author for correction and another test/review.
4. The authorized publisher selects Publish after approval. Refresh the source setup screen.
5. For a published connection, verify Refresh snapshot and inspect the result. This refresh changes the source data snapshot; it does not silently edit approved source field definitions.
Expected result
The connection becomes published and eligible for source-definition selection. A fresh successful test is required for the revision being submitted/reviewed.
Connection test eligibility is time-limited (30 minutes in the inspected implementation). A changed revision, expired test or changed authorization requires a new test. Publication of a connection does not create a dataset or report.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The connection becomes published and eligible for source-definition selection. A fresh successful test is required for the revision being submitted/reviewed.,documentation/KERNEL_DOCUMENTATION_HUB.html#pulse-demo/step-1-2,R1-G04; R1-G06,Not run,,,,,,,Not run,
PULSE-01-03,R1-PULSE-01,Pulse,Prepare the source and reviewed datasets,Module journey,P1,Vista → Sources & datasets → Source definitions → New source,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Vista → Sources & datasets → Source definitions → New source | 
Who acts | Maker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Maker
Open: Vista → Sources & datasets → Source definitions → New source
1. Enter Source name: Service records and Source code: DEMO_SERVICE_SOURCE, with your unique suffix.
2. Select the approved published connection from the connection selector.
3. Select the discovered fields needed by the demo, including record_id and the numeric amount. Include the contact fields only when the intended readers are authorized to use them.
4. Save source draft. Preview the saved source and inspect its current rows and field contract.
5. Submit for review. The independent Checker opens the same source row, performs its own preview, checks field exposure and approves or returns.
6. Publish the approved source. Refresh Datasets or the Studio source-selection step.
7. Repeat for the optional Service line items source using its corresponding approved connection/registered source.
Screen 2Source Definitions is the named-source masterExisting application recorded test · example records may differ from your tenant · click to enlarge
• Connections, Source Definitions and Datasets are separate tabs.
• New source defines a reusable field set from a connection; Create dataset consumes a published source.
Expected result
Service records appears as a published source. Its name and field contract are available to dataset builders with the correct scope.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Service records appears as a published source. Its name and field contract are available to dataset builders with the correct scope.,documentation/KERNEL_DOCUMENTATION_HUB.html#pulse-demo/step-1-3,R1-G04; R1-G06,Not run,,,,,,,Not run,
PULSE-01-04,R1-PULSE-01,Pulse,Prepare the source and reviewed datasets,Module journey,P1,Vista → Sources & datasets → Datasets → New dataset,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Vista → Sources & datasets → Datasets → New dataset | 
Who acts | Maker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Maker
Open: Vista → Sources & datasets → Datasets → New dataset
1. Enter Dataset name: Service review dataset and Dataset code: DEMO_SERVICE_DATA.
2. Choose Select fields from one source and select Service records.
3. Select record_id, recipient_name, recipient_address, organisation_name, reference, correspondence_date, recipient_email, region, status and amount. Check the actual types, especially numeric amount.
4. Save dataset draft. Open Preview from the saved row. Verify CASE1001 and its authorized values; an empty result must be understood rather than filled with invented records.
5. Return to the dataset row and choose Submit for review.
6. Checker uses its own profile and Preview on the same saved revision, inspects fields/data/scope, then Approve or Return.
7. Publish the approved dataset. It is now eligible for the report/Pulse Studio setup. Prepare and publish Service line items similarly if using repeated content.
Expected result
A published dataset with a stable field contract is selectable in Studio. Merely saving a draft does not expose it for general report building.
Dataset preview shows up to 50 current authorized rows. Its review eligibility belongs to the saved revision and selected profile and lasts 15 minutes in the inspected implementation. Changing the draft or profile, or waiting past expiry, requires another preview. The independent Checker must obtain its own preview.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",A published dataset with a stable field contract is selectable in Studio. Merely saving a draft does not expose it for general report building.,documentation/KERNEL_DOCUMENTATION_HUB.html#pulse-demo/step-1-4,R1-G04; R1-G06,Not run,,,,,,,Not run,
PULSE-01-05,R1-PULSE-01,Pulse,Prepare the source and reviewed datasets,Module journey,P1,"New dataset → Dataset structure → Model sources, joins and calculations","Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | New dataset → Dataset structure → Model sources, joins and calculations | 
Who acts | Maker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Maker
Open: New dataset → Dataset structure → Model sources, joins and calculations
1. Choose the primary source with alias main. Add a second source with alias lookup or items, and select the required input fields.
2. Join compatible keys. For the example, main.record_id joins items.case_id. Use LEFT to retain a primary record without items, or INNER to keep matches only.
3. Add selected fields as outputs. Give outputs distinct lowercase names. Add a calculated field, such as line_amount × a numeric constant, using the expression controls.
4. Add a filter only when it expresses the intended business subset, such as status equals OPEN. Explain how it changes the totals.
5. Preview the model. Inspect duplicate keys and row multiplication before interpreting counts or sums. Do not sum parent amount after a one-to-many join without accounting for repeated parent rows.
6. Save, preview, independently review and publish the modelled dataset exactly as for the simple dataset.
Screen 3Dataset model: selected sources and fieldsExisting application recorded test · example records may differ from your tenant · click to enlarge
• The model uses compatible registered field types and source versions.
• Each additional source needs a join; all outputs are explicit.
Screen 4Checker previews the saved dataset modelExisting application recorded test · example records may differ from your tenant · click to enlarge
• This earlier recorded test shows joined current data.
• Review actual values and cardinality; the screenshot is not the Service review example.
Model feature | Inspected support | 
Sources / joins | 1–3 sources; INNER and LEFT joins; compatible key types | 
Outputs / filters | 1–40 named outputs; up to 12 boolean filters | 
Numeric expressions | Add, subtract, multiply, divide, round | 
Text/date expressions | Uppercase, lowercase, trim, concatenate, year from a date | 
Conditions / nulls | Comparisons, contains, AND/OR/NOT, is-empty, fallback when empty | 
Runtime behavior | Null join keys do not match; division by zero produces empty output; current access still applies | 
For the simple user walkthrough, keep the primary dataset one row per case. Use Pulse’s related-record collections for line items. A modelled dataset is the supported way to supply a report’s one primary dataset from several sources.
Check before continuing: The saved dataset model has the intended selected fields, types, joins and calculated values. Its current preview and independent decision apply to that exact revision.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The saved dataset model has the intended selected fields, types, joins and calculated values. Its current preview and independent decision apply to that exact revision.",documentation/KERNEL_DOCUMENTATION_HUB.html#pulse-demo/step-1-5,R1-G04; R1-G06,Not run,,,,,,,Not run,
PULSE-02-01,R1-PULSE-02,Pulse,Create and publish an email template,Module journey,P1,"New report, New dashboard, Create email template or Create letter template",Use a published authorized dataset with a stable key and a controlled fictional record such as CASE1001. Prepare related rows if the template uses repeats. Select a maker and independent checker. For output-only demonstrations use clearly fictional addresses; for actual sending use an authorized controlled recipient and configured live transport.,"Before you act | Required context | 
Screen / entry | New report, New dashboard, Create email template or Create letter template | 
Who acts | Maker | 
You need | Use a published authorized dataset with a stable key and a controlled fictional record such as CASE1001. Prepare related rows if the template uses repeats. Select a maker and independent checker. For output-only demonstrations use clearly fictional addresses; for actual sending use an authorized controlled recipient and configured live transport. | 
Steps and field guidance
Who: Maker
Open: New report, New dashboard, Create email template or Create letter template
1. Sources: Define or choose sources. Select the published source(s) used by your dataset. Define source opens the source master when authorized.
2. Datasets: Build or choose datasets that match those selected sources. Build dataset opens the dataset master. Newly created items become selectable after review and publication.
3. Basic details: Type the artifact’s name and code. Verify the chosen source/dataset summary.
4. Studio: Select Open Studio. Start from a blank canvas, then optionally choose a template/layout from the toolbar.
Screen 5First select the sourcesExisting application recorded test · example records may differ from your tenant · click to enlarge
• Selection reflects current profile access.
• The same setup pattern is used by Vista and Pulse.
Screen 6Then name the artifact before opening StudioExisting application recorded test · example records may differ from your tenant · click to enlarge
• Basic details retain the source/dataset selection.
• Open Studio begins composition; it does not publish anything.
A report and Pulse template use one primary dataset. A modelled dataset can combine sources. Dashboard setup can select multiple datasets, but its tiles come from published report visuals. Selecting a source alone does not supply a report layout.
Check before continuing: The artifact has the intended source(s), eligible dataset(s), name and basic details before Studio opens. The selected context is carried into the saved draft.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The artifact has the intended source(s), eligible dataset(s), name and basic details before Studio opens. The selected context is carried into the saved draft.",documentation/KERNEL_DOCUMENTATION_HUB.html#pulse-demo/step-2-1,R1-G04; R1-G06,Not run,,,,,,,Not run,
PULSE-02-02,R1-PULSE-02,Pulse,Create and publish an email template,Module journey,P1,Pulse email or letter creation → shared source/dataset setup → Dataset binding,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Pulse email or letter creation → shared source/dataset setup → Dataset binding | 
Who acts | Maker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Maker
Open: Pulse email or letter creation → shared source/dataset setup → Dataset binding
1. Choose Service review dataset as the primary published dataset. In Dataset binding select record_id as Unique record field.
2. Map Recipient name → recipient_name, Recipient address → recipient_address, Organization name → organisation_name, Reference → reference, Date → correspondence_date. Map only fields used in the content.
3. For related line items choose Add related dataset. Use collection name items, select Service line items, and match its case_id to the parent record key.
4. Select item_id, description and line_amount as related fields; choose item_id for ordering.
5. Insert a Repeating table block and select items. Give the displayed columns readable headings.
6. Choose the actual CASE1001 record later in the saved preview or generation request. The template stores the dataset and mapping, not a permanently frozen copy of that record’s values.
Screen 7Pulse saves the primary and related-record bindingsExisting application recorded test · example records may differ from your tenant · click to enlarge
• The screenshot’s test fields differ from the Service review example.
• Related rows match the selected parent key and appear in the saved rendered preview.
Expected result
Both template channels use the same published dataset contract, a unique parent record key and an explicit set of merge-field mappings.
The inspected related-content implementation permits up to two related datasets, 50 matching rows each and up to eight selected fields per collection. Every dataset remains subject to current access. An ambiguous/non-unique parent key is a data problem, not a reason to pick an arbitrary record.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","Both template channels use the same published dataset contract, a unique parent record key and an explicit set of merge-field mappings.",documentation/KERNEL_DOCUMENTATION_HUB.html#pulse-demo/step-2-2,R1-G04; R1-G06,Not run,,,,,,,Not run,
PULSE-02-03,R1-PULSE-02,Pulse,Create and publish an email template,Module journey,P1,Pulse → Templates → Email templates → New template,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Pulse → Templates → Email templates → New template | 
Who acts | Maker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Maker
Open: Pulse → Templates → Email templates → New template
1. Complete source/dataset selection and enter Service review email / DEMO_SERVICE_EMAIL. Open the blank Studio and configure the binding from the previous chapter.
2. Set Email Subject to Service review update and Inbox Preview Text to Your current service summary and next steps. Insert offered merge fields only where supported.
3. Add a heading, greeting using Recipient name, a paragraph containing Reference and Date, and a clear next-step message.
4. Add the items Repeating table. Optionally use a two-column content block for Summary and Next steps.
5. Use the inspector for alignment, spacing, colors and supported conditional content. Select placeholders from the offered field list; do not type unsupported variables.
6. Use Design/Preview and Mobile Preview to inspect the email at desktop and narrow widths. Check button/link text and a valid intended destination if adding a link.
7. Save the draft. The channel is email; it is separate from a letter template even when the text is similar.
Screen 8Email Studio: saved dataset binding, subject and preview controlsExisting application recorded test · example records may differ from your tenant · click to enlarge
• A design or mobile preview helps composition.
• The review gate uses Render saved preview after saving.
Screen 9Earlier rendered email at a narrow widthExisting application recorded test · example records may differ from your tenant · click to enlarge
• Related rows and columns must stay readable at mobile width.
• This is rendered recorded test content, not a sent-message receipt.
Expected result
A saved email draft includes subject, preheader, content blocks and its data contract. No message has been sent.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","A saved email draft includes subject, preheader, content blocks and its data contract. No message has been sent.",documentation/KERNEL_DOCUMENTATION_HUB.html#pulse-demo/step-2-3,R1-G04; R1-G06,Not run,,,,,,,Not run,
PULSE-02-04,R1-PULSE-02,Pulse,Create and publish an email template,Module journey,P1,Email templates → saved record → Preview,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Email templates → saved record → Preview | 
Who acts | Maker → independent Checker → Publisher | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Maker → independent Checker → Publisher
Open: Email templates → saved record → Preview
1. Choose Preview on the saved row, or the saved-preview panel after saving in Studio. Verify the dataset and mappings loaded from that saved revision.
2. Enter Exact record value CASE1001, or use Find current rows and select it. Select Render saved preview. If queued, wait or use Check preview.
3. Inspect the rendered HTML and bound values. Tick I reviewed this saved version with the selected data.
4. Supply a meaningful Review note (at least 10 characters for the Studio submission) and submit the template for review.
5. Checker opens the same row under its own identity, renders its own saved preview, inspects it, acknowledges it and selects Approve. Use Return with a reason when correction is needed.
6. Publish the approved version. Confirm Published on the Email templates row.
7. Use the published template’s Generate email action when offered. Enter the sender/recipient email fields and the intended record/input values. For this example use controlled values; generation alone does not send.
8. Open Generated Emails, refresh for completion and download the generated email file when authorized. Inspect both its plain-text and HTML parts.
Screen 10Published email template in the originating masterExisting application recorded test · example records may differ from your tenant · click to enlarge
• Preview and state-eligible actions remain with the template row.
• The Published state makes this version eligible for generation and a Scheduler job.
Expected result
The template is published and a separate generation request produces the email file. Keep both the template version and generation reference.
Preview evidence is tied to revision, content and profile and expires. Editing, changing context or using an expired receipt requires rendering again. The creator’s preview does not stand in for the Checker’s independent preview.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The template is published and a separate generation request produces the email file. Keep both the template version and generation reference.,documentation/KERNEL_DOCUMENTATION_HUB.html#pulse-demo/step-2-4,R1-G04; R1-G06,Not run,,,,,,,Not run,
PULSE-03-01,R1-PULSE-03,Pulse,Create and publish a letter template,Module journey,P1,"New report, New dashboard, Create email template or Create letter template",Use a published authorized dataset with a stable key and a controlled fictional record such as CASE1001. Prepare related rows if the template uses repeats. Select a maker and independent checker. For output-only demonstrations use clearly fictional addresses; for actual sending use an authorized controlled recipient and configured live transport.,"Before you act | Required context | 
Screen / entry | New report, New dashboard, Create email template or Create letter template | 
Who acts | Maker | 
You need | Use a published authorized dataset with a stable key and a controlled fictional record such as CASE1001. Prepare related rows if the template uses repeats. Select a maker and independent checker. For output-only demonstrations use clearly fictional addresses; for actual sending use an authorized controlled recipient and configured live transport. | 
Steps and field guidance
Who: Maker
Open: New report, New dashboard, Create email template or Create letter template
1. Sources: Define or choose sources. Select the published source(s) used by your dataset. Define source opens the source master when authorized.
2. Datasets: Build or choose datasets that match those selected sources. Build dataset opens the dataset master. Newly created items become selectable after review and publication.
3. Basic details: Type the artifact’s name and code. Verify the chosen source/dataset summary.
4. Studio: Select Open Studio. Start from a blank canvas, then optionally choose a template/layout from the toolbar.
Screen 11First select the sourcesExisting application recorded test · example records may differ from your tenant · click to enlarge
• Selection reflects current profile access.
• The same setup pattern is used by Vista and Pulse.
Screen 12Then name the artifact before opening StudioExisting application recorded test · example records may differ from your tenant · click to enlarge
• Basic details retain the source/dataset selection.
• Open Studio begins composition; it does not publish anything.
A report and Pulse template use one primary dataset. A modelled dataset can combine sources. Dashboard setup can select multiple datasets, but its tiles come from published report visuals. Selecting a source alone does not supply a report layout.
Check before continuing: The artifact has the intended source(s), eligible dataset(s), name and basic details before Studio opens. The selected context is carried into the saved draft.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The artifact has the intended source(s), eligible dataset(s), name and basic details before Studio opens. The selected context is carried into the saved draft.",documentation/KERNEL_DOCUMENTATION_HUB.html#pulse-demo/step-3-1,R1-G04; R1-G06,Not run,,,,,,,Not run,
PULSE-03-02,R1-PULSE-03,Pulse,Create and publish a letter template,Module journey,P1,Pulse email or letter creation → shared source/dataset setup → Dataset binding,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Pulse email or letter creation → shared source/dataset setup → Dataset binding | 
Who acts | Maker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Maker
Open: Pulse email or letter creation → shared source/dataset setup → Dataset binding
1. Choose Service review dataset as the primary published dataset. In Dataset binding select record_id as Unique record field.
2. Map Recipient name → recipient_name, Recipient address → recipient_address, Organization name → organisation_name, Reference → reference, Date → correspondence_date. Map only fields used in the content.
3. For related line items choose Add related dataset. Use collection name items, select Service line items, and match its case_id to the parent record key.
4. Select item_id, description and line_amount as related fields; choose item_id for ordering.
5. Insert a Repeating table block and select items. Give the displayed columns readable headings.
6. Choose the actual CASE1001 record later in the saved preview or generation request. The template stores the dataset and mapping, not a permanently frozen copy of that record’s values.
Screen 13Pulse saves the primary and related-record bindingsExisting application recorded test · example records may differ from your tenant · click to enlarge
• The screenshot’s test fields differ from the Service review example.
• Related rows match the selected parent key and appear in the saved rendered preview.
Expected result
Both template channels use the same published dataset contract, a unique parent record key and an explicit set of merge-field mappings.
The inspected related-content implementation permits up to two related datasets, 50 matching rows each and up to eight selected fields per collection. Every dataset remains subject to current access. An ambiguous/non-unique parent key is a data problem, not a reason to pick an arbitrary record.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","Both template channels use the same published dataset contract, a unique parent record key and an explicit set of merge-field mappings.",documentation/KERNEL_DOCUMENTATION_HUB.html#pulse-demo/step-3-2,R1-G04; R1-G06,Not run,,,,,,,Not run,
PULSE-03-03,R1-PULSE-03,Pulse,Create and publish a letter template,Module journey,P1,Pulse → Templates → Letter templates → New template,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Pulse → Templates → Letter templates → New template | 
Who acts | Maker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Maker
Open: Pulse → Templates → Letter templates → New template
1. Complete source/dataset selection and enter Service review letter / DEMO_SERVICE_LETTER. Open the blank Studio and apply the same primary/related-record binding.
2. Choose paper size (for example Letter for the US walkthrough) and suitable margins. Add organization heading, Recipient name/address, Date and Reference using the offered fields.
3. Add the body and the items Repeating table. Inspect table column widths and long descriptions.
4. Insert a Page Break before an appendix or terms section. Add enough controlled sample content/related rows to exercise more than one page.
5. Use the template/layout dropdown only if you want a starting design. Inspect all resulting blocks; selected recipes still need correct data mappings.
6. Optionally save a selected block as a reusable section and insert it into another draft. Inserted sections are independent copies; later library edits do not silently update published templates.
7. Save the draft. Render saved preview for CASE1001 and inspect the actual PDF, including every page, wrapping, margins and repeated table headings.
Screen 14Letter Studio with repeating data and reusable sectionsExisting application recorded test · example records may differ from your tenant · click to enlarge
• Planned page layout can grow when actual records are rendered.
• Use the saved PDF preview to verify pagination, not just the design canvas.
Expected result
A saved letter draft renders a readable PDF using the selected record. The page-break walkthrough shows a real additional page in the rendered file.
The inspected local renderer embeds fonts and honors page breaks and margins. Do not equate successful rendering with PDF/A certification, accessibility tagging, postal dispatch or fax delivery. Those require their own capabilities and acceptance.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",A saved letter draft renders a readable PDF using the selected record. The page-break walkthrough shows a real additional page in the rendered file.,documentation/KERNEL_DOCUMENTATION_HUB.html#pulse-demo/step-3-3,R1-G04; R1-G06,Not run,,,,,,,Not run,
PULSE-03-04,R1-PULSE-03,Pulse,Create and publish a letter template,Module journey,P1,Letter templates → saved record → Preview,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Letter templates → saved record → Preview | 
Who acts | Maker → independent Checker → Publisher | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Maker → independent Checker → Publisher
Open: Letter templates → saved record → Preview
1. After inspecting the saved PDF, acknowledge the saved-version preview and submit the draft for review with a meaningful note.
2. Checker renders the same saved revision with its own current data access, checks recipient/address and every page, acknowledges the preview and approves or returns.
3. Publish the approved letter. Verify the Published status and version on its row.
4. Use the published letter’s Render / PDF request action when offered. Supply the intended record key for a saved data binding, or the explicitly required manual merge values.
5. Open Rendered letters. Refresh until READY or an explicit failure. Download the verified PDF when authorized and inspect the final recipient, reference, date and page count.
6. If rendering fails, correct the cause and use the supported new request/rerun process; retain the failed job history.
Screen 15Published letter with preview and lifecycle actionsExisting application recorded test · example records may differ from your tenant · click to enlarge
• The letter is a versioned artifact; its rendered PDF is a separate output.
• Use the current row actions rather than manually composing record URLs.
Expected result
A published letter and a READY PDF output exist as distinct records. Their identifiers are ready to compare with Scheduler results.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",A published letter and a READY PDF output exist as distinct records. Their identifiers are ready to compare with Scheduler results.,documentation/KERNEL_DOCUMENTATION_HUB.html#pulse-demo/step-3-4,R1-G04; R1-G06,Not run,,,,,,,Not run,
PULSE-04-01,R1-PULSE-04,Pulse,Operate delivery and notifications,Module journey,P1,Create Channel and select the appropriate channel/provider/mode in its configuration control.,Use a published authorized dataset with a stable key and a controlled fictional record such as CASE1001. Prepare related rows if the template uses repeats. Select a maker and independent checker. For output-only demonstrations use clearly fictional addresses; for actual sending use an authorized controlled recipient and configured live transport.,"Before you act | Required context | 
Screen / entry | Create Channel and select the appropriate channel/provider/mode in its configuration control. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Use a published authorized dataset with a stable key and a controlled fictional record such as CASE1001. Prepare related rows if the template uses repeats. Select a maker and independent checker. For output-only demonstrations use clearly fictional addresses; for actual sending use an authorized controlled recipient and configured live transport. | 
Steps and field guidance
Before you start: The provider and sender/recipient policy are approved; credentials are available by reference.
1. Open Create Channel and select the appropriate channel/provider/mode in its configuration control.
2. Enter the required sender, endpoint and credential-reference fields. Save and inspect Channel Setup.
3. Keep draft/not-tested state visible until the connection has passed its intended delivery verification.
4. Open Create Notification Rule, choose the supported event/severity/channel configuration and cooldown.
5. Inspect Notification Rules and test with an authorized controlled event; verify the resulting inbox/delivery evidence.
The connection and event rule are recorded without claiming unverified live transport.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The connection and event rule are recorded without claiming unverified live transport.,documentation/KERNEL_DOCUMENTATION_HUB.html#pulse-demo/step-4-1,R1-G04; R1-G06,Not run,,,,,,,Not run,
PULSE-04-02,R1-PULSE-04,Pulse,Operate delivery and notifications,Module journey,P1,Delivery attempts and inspect the local receipt and captured-output hash,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Delivery attempts and inspect the local receipt and captured-output hash | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Evidence | What it proves | What it does not prove | 
Saved Studio preview | The saved content renders with selected authorized data | Publication, scheduled execution or sending | 
Published template | An approved version is eligible for use | A recipient has received anything | 
Generated email / READY PDF | The producer created an output | SMTP delivery, print, postal acceptance or fax completion | 
Capture locally / LOCAL_CAPTURED | A local receipt records the output and endpoint revision | External sending or provider delivery | 
Provider acceptance, when a separate integration is configured | The provider accepted that delivery request | Final delivery unless a later provider receipt explicitly confirms it | 
1. For a local delivery walkthrough, open a generated email and select Capture locally when eligible. Choose an existing matching-channel endpoint configured in LOCAL mode and its current revision.
2. Open Delivery attempts and inspect the local receipt and captured-output hash. Note that local capture is intentionally separate from sending.
3. If using a separately configured live transport, trace its own request, provider reference and final callback/status. Use a controlled recipient and the transport’s authorized send action.
4. If no such transport is configured, finish this part at generated output/local receipt and state that external dispatch is not part of this completed run.
The current Pulse Delivery attempts screen describes local capture receipts. The inspected Scheduler capabilities are Generate published Pulse email and Generate published Pulse letter. They do not supply a universal send-mail/print/fax operation or automatically attach a Vista report to an email. Do not promise those effects from a generation job.
Check before continuing: The latest attempt has an attributable provider state or an explicit configuration blocker; generation is not counted as delivery.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The latest attempt has an attributable provider state or an explicit configuration blocker; generation is not counted as delivery.,documentation/KERNEL_DOCUMENTATION_HUB.html#pulse-demo/step-4-2,R1-G04; R1-G06,Not run,,,,,,,Not run,
PULSE-04-03,R1-PULSE-04,Pulse,Operate delivery and notifications,Module journey,P1,"the header bell and read the notification’s subject, status and available action.","Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | the header bell and read the notification’s subject, status and available action. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Before you start: Sign in with the intended recipient account and correct profile.
1. Open the header bell and read the notification’s subject, status and available action.
2. Use the record-specific action/link to open the referenced item.
3. If sign-in is required, authenticate and return to the link; choose an eligible profile if prompted.
4. Inspect the business item’s current state and perform only the action offered by its owner workflow.
5. Mark the notification read when appropriate. Reading it does not approve or complete the business item.
Navigation preserves recipient and record authority; expired or inaccessible work is handled by the target owner.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Navigation preserves recipient and record authority; expired or inaccessible work is handled by the target owner.,documentation/KERNEL_DOCUMENTATION_HUB.html#pulse-demo/step-4-3,R1-G04; R1-G06,Not run,,,,,,,Not run,
PULSE-04-04,R1-PULSE-04,Pulse,Operate delivery and notifications,Module journey,P1,the ready Correspondence Request and choose Send to Custodia.,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | the ready Correspondence Request and choose Send to Custodia. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Before you start: The output is ready and an approved compatible Custodia class is available.
1. Open the ready Correspondence Request and choose Send to Custodia.
2. Select the approved class and enter the document title.
3. Submit and inspect Custodia Handoffs for the immutable transfer receipt.
4. Open the Custodia record and follow its admission, metadata and custody process.
5. Distinguish the transfer-time Stored in Quarantine receipt from later admission or archival results.
The owner’s bytes are transferred with matching digest and canonical document identity.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The owner’s bytes are transferred with matching digest and canonical document identity.,documentation/KERNEL_DOCUMENTATION_HUB.html#pulse-demo/step-4-4,R1-G04; R1-G06,Not run,,,,,,,Not run,
PULSE-05-01,R1-PULSE-05,Pulse,Schedule published Pulse output,Module journey,P1,Job Definitions and start a new draft only after the intended business artifact is published.,Use a published authorized dataset with a stable key and a controlled fictional record such as CASE1001. Prepare related rows if the template uses repeats. Select a maker and independent checker. For output-only demonstrations use clearly fictional addresses; for actual sending use an authorized controlled recipient and configured live transport.,"Before you act | Required context | 
Screen / entry | Job Definitions and start a new draft only after the intended business artifact is published. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Use a published authorized dataset with a stable key and a controlled fictional record such as CASE1001. Prepare related rows if the template uses repeats. Select a maker and independent checker. For output-only demonstrations use clearly fictional addresses; for actual sending use an authorized controlled recipient and configured live transport. | 
Steps and field guidance
1. Open Job Definitions and start a new draft only after the intended business artifact is published.
2. Select the registered operation that matches the artifact and output in the table below.
3. Confirm the Run as identity can access that artifact and its source data. Continue to the job-definition procedure to save, preview and govern the exact binding.
Content / purpose | Registered business operation | Produced result | 
Source connection | NEXUS_SOURCE_REFRESH_V1 · Refresh published source connection | New authorized source snapshot | 
Vista report | VISTA_REPORT_V1 · Run published Vista report | Published report output | 
Vista dashboard | VISTA_DASHBOARD_V1 · Run published Vista dashboard (registered operation version 2) | Dashboard snapshot with all report tiles checked | 
Pulse email | PULSE_EMAIL_V1 · Generate published Pulse email | Generated email file; sending is separate | 
Pulse letter | PULSE_LETTER_V1 · Generate published Pulse letter | Rendered letter/PDF output | 
Private draft maintenance | VISTA_RECOVERY_CLEANUP_V1 / PULSE_RECOVERY_CLEANUP_V1 | Bounded removal of expired recovery copies; maintenance permission required | 
Published artifact + authorized Run as identity + inputs → reviewed Job Definition → published version → Schedule / Run now / Batch step → worker → owning producer → result reference
A dataset is consumed by a report/template or used for job input binding. It is not automatically a standalone executable job. The source refresh operation refreshes a published connection’s snapshot. Additional external business operations must be registered with a supported input/result contract and permission model before they appear in the selector.
Expected result
The operator can identify which owning module produces the result and which job/schedule/run record coordinates it.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The operator can identify which owning module produces the result and which job/schedule/run record coordinates it.,documentation/KERNEL_DOCUMENTATION_HUB.html#pulse-demo/step-5-1,R1-G04; R1-G06,Not run,,,,,,,Not run,
PULSE-05-02,R1-PULSE-05,Pulse,Schedule published Pulse output,Module journey,P1,Scheduler → Job Definitions → New job,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Scheduler → Job Definitions → New job | 
Who acts | Scheduler Maker → independent Checker → Publisher | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Scheduler Maker → independent Checker → Publisher
Open: Scheduler → Job Definitions → New job
1. Choose Generate published Pulse email or Generate published Pulse letter as the Business operation. Select an approved Run as identity with access to the template and its bound datasets.
2. Enter a unique Job code, recognizable Job name and description. In Published content choose the required published template and exact version; the selector supplies its revision and content hash.
3. For a bound template supply the exact parent Record key, such as CASE1001 from the prepared dataset. Check the saved primary and related-record mappings against the current authorized data.
4. For an email job, enter the controlled sender and recipient in the offered contract inputs. For a letter job, use its offered record, reason and merge inputs; do not add email-only inputs.
5. Set a suitable timeout, maximum attempts and overlap policy. Start the initial UAT execution with one attempt; verify retry behavior separately after understanding possible effects.
6. Save the draft and use Preview on its row. Inspect the operation, execution identity, resolved input values and pinned content. Preview resolves inputs; it does not generate the output.
7. Submit the saved job for review. A different eligible checker previews the same revision and approves or returns it with a reason. Publish the approved job.
8. Retain the published job version. Continue to Run a job and inspect its producer result before enabling a schedule.
Output | Registered operation | Verify before publication | 
Email | PULSE_EMAIL_V1 | Published email template; sender/recipient; primary record key; current dataset access. | 
Letter | PULSE_LETTER_V1 | Published letter template; primary record key; repeated content and pagination. | 
A published job generates output under its selected execution identity. Sending, faxing, printing or mailing needs the corresponding configured delivery flow. Publishing a template successor does not automatically update an existing job.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","A published job generates output under its selected execution identity. Sending, faxing, printing or mailing needs the corresponding configured delivery flow. Publishing a template successor does not automatically update an existing job.",documentation/KERNEL_DOCUMENTATION_HUB.html#pulse-demo/step-5-2,R1-G04; R1-G06,Not run,,,,,,,Not run,
PULSE-05-03,R1-PULSE-05,Pulse,Schedule published Pulse output,Module journey,P1,Job definition → Inputs,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Job definition → Inputs | 
Who acts | Scheduler Maker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Scheduler Maker
Open: Job definition → Inputs
1. Choose an input permitted by the selected operation’s schema. For example, bind the email job’s recipient to the authorized primary dataset’s recipient_email.
2. Set Input source to Dataset field. Select the published dataset, value field recipient_email, unique key field record_id and exact record CASE1001.
3. Add the input and inspect the resulting input grid. Keep Record key consistent with the Pulse template’s intended parent record.
4. Save and Preview. Confirm the currently resolved value and its dataset version/contract. Submit/review/publish the changed definition as required.
5. At execution the binding is read and validated again. Verify a changed value only using a controlled source update followed by the required snapshot refresh; then compare the actual output.
Expected result
The job reads a current authorized value for one explicitly selected record. Missing access, missing/ambiguous keys or incompatible values fail rather than silently using an unrelated record.
Dataset field binding is not “run once per every dataset row.” The inspected input model selects one record per binding. Do not claim bulk-recipient fan-out, arbitrary output-to-input piping or a generic ETL loop. Use a registered business operation for any additional bulk behavior.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The job reads a current authorized value for one explicitly selected record. Missing access, missing/ambiguous keys or incompatible values fail rather than silently using an unrelated record.",documentation/KERNEL_DOCUMENTATION_HUB.html#pulse-demo/step-5-3,R1-G04; R1-G06,Not run,,,,,,,Not run,
PULSE-05-04,R1-PULSE-05,Pulse,Schedule published Pulse output,Module journey,P1,Scheduler → Job Runs → Run a job,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Scheduler → Job Runs → Run a job | 
Who acts | Authorized Scheduler operator | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Authorized Scheduler operator
Open: Scheduler → Job Runs → Run a job
1. Select the published Service report generation job. Preview current inputs, provide the execution reason and select Queue run. Record the run reference.
2. Refresh the run. Follow Queued → Claimed/Running → Waiting external where applicable → Succeeded or an explicit failure.
3. Open Details. Inspect the exact job version, attempt information, execution timestamps and Producer result reference.
4. Repeat for the dashboard, email and letter jobs, one at a time for the user walkthrough.
5. For each producer result, open the appropriate authorized Vista/Pulse output screen or access-controlled result view. Compare it with the manual output and intended case.
6. Record actual outcomes in LIVE_DEMO_CHECKLIST.csv. Do not mark a queued/accepted job as a successful generated output.
Job | Required success evidence | Extra check | 
Report | Scheduler SUCCEEDED + completed report result reference | Expected dataset scope, values and published report version | 
Dashboard | Scheduler SUCCEEDED + completed snapshot | Every tile available; PARTIAL is not success | 
Email | Scheduler SUCCEEDED + READY generated-email reference | Correct record, sender/recipient in file; no claim of send | 
Letter | Scheduler SUCCEEDED + READY letter/PDF reference | Correct recipient/reference and pagination | 
Scheduled work can run as a service identity different from the operator. Producer output lists are access-controlled and may be requester-scoped. A result absent from the operator’s personal Generated Emails/Rendered letters list is not proof that no output exists. Use the authorized result access path and the scheduler’s recorded producer reference; do not broaden permissions just to expose another identity’s output.
Expected result
All four actual executions have a result reference and a verified output. Rehearse these before enabling a recurring schedule.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",All four actual executions have a result reference and a verified output. Rehearse these before enabling a recurring schedule.,documentation/KERNEL_DOCUMENTATION_HUB.html#pulse-demo/step-5-4,R1-G04; R1-G06,Not run,,,,,,,Not run,
PULSE-05-05,R1-PULSE-05,Pulse,Schedule published Pulse output,Module journey,P1,Scheduler → Schedules → New schedule,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Scheduler → Schedules → New schedule | 
Who acts | Scheduler Maker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Scheduler Maker
Open: Scheduler → Schedules → New schedule
1. Select the published job version. Enter name/code, for example Service report weekday schedule / DEMO_REPORT_SCHEDULE.
2. For the first live execution choose Run once and a future execution time with enough time to complete review. Enter the UTC instant in the field explicitly labelled UTC.
3. Choose the display/calendar Time zone. Inspect both UTC and local time in Preview rather than relying on the browser’s timezone.
4. For repetition choose Fixed elapsed interval with a UTC anchor and interval seconds, or Calendar schedule with a five-field cron expression.
5. Optionally select a published Business calendar. It pins that calendar version and constrains the schedule to its allowed dates/windows.
6. Choose the missed-execution policy and limits. Save draft, Preview upcoming dates and current input bindings, then Submit for review.
7. Checker performs its own current Preview and Approve or Return. An authorized publisher uses Publish and enable when the approved revision has a fresh preview.
8. Open Job Runs after the occurrence. Verify the schedule’s run and producer result, then pause or retire the demo schedule after use.
Screen 16Schedule timing, calendar and missed-execution behaviorExisting application recorded test · example records may differ from your tenant · click to enlarge
• A schedule pins an exact published job version.
• Saving a draft does not enable execution.
Trigger | Example | Use | 
Run once | A chosen future UTC instant | One client-demo execution | 
Fixed elapsed interval | Anchor in UTC; every 3600 seconds | Elapsed hourly cadence independent of local DST | 
Calendar schedule | 0 9 * * 1-5 in the chosen timezone | 09:00 on weekdays | 
Calendar schedule | 0 9 * * 1 | Monday at 09:00 | 
Calendar schedule | 0 9 1 * * | First day of each month at 09:00 | 
Create separate schedules for the email, letter and dashboard jobs using the same procedure when they need independent timing. A schedule is a job trigger; the inspected schedule selector does not establish timer-triggered batch execution. Verify batch execution through Batches, as described later.
Check before continuing: The saved reviewed schedule references the intended published job version, timezone and calendar. Its upcoming occurrences and missed-execution behavior match the requested timing.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The saved reviewed schedule references the intended published job version, timezone and calendar. Its upcoming occurrences and missed-execution behavior match the requested timing.",documentation/KERNEL_DOCUMENTATION_HUB.html#pulse-demo/step-5-5,R1-G04; R1-G06,Not run,,,,,,,Not run,
PULSE-05-06,R1-PULSE-05,Pulse,Schedule published Pulse output,Module journey,P1,"Job Runs, Schedules and Job Definitions → eligible row actions","Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Job Runs, Schedules and Job Definitions → eligible row actions | 
Who acts | Authorized operator | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
1. Open the existing run, schedule or job and inspect its current status and last producer result.
2. Choose the single action that matches your need from the table below. Check the effect on already accepted work before confirming.
3. For a rerun, preview current inputs and supply the reason; for schedule resumption, inspect upcoming dates and missed-execution behavior.
4. Confirm the eligible action once. Refresh the originating record, retain the new receipt/reference and compare it with the original history.
Who: Authorized operator
Open: Job Runs, Schedules and Job Definitions → eligible row actions
Action | Procedure | Important effect | 
Rerun a completed/failed eligible run | Open run → Rerun → Preview current inputs → reason → Queue run | New linked run; same approved job version; current data may differ | 
Cancel queued run | Select Cancel queued run and confirm the reason | Only eligible queued work; not a rollback of accepted external work | 
Pause schedule | Open eligible schedule row → Pause → reason | Stops future scheduling; already accepted/queued runs remain separate | 
Resume schedule | Preview upcoming dates/current inputs, then Resume when eligible | Missed-execution policy governs the resumption | 
Retire schedule | Use its offered retirement action and reason | Retains historical occurrences/runs | 
Retire job | Use the job’s permitted retirement action | Stops new runs for the retired job; accepted work/history are retained | 
Create new job version | Branch/edit the supported draft → save → preview → review → publish | Dependents must explicitly select the new published version | 
Do not rerun uncertain external effects merely because the screen timed out. Reconciliation-required runs block automatic rerun. Changing a record to inactive or retired is not a universal cancellation or deletion mechanism.
Expected result
Every operator action has a reason and a retained audit trail. The original failed run is still visible after recovery.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Every operator action has a reason and a retained audit trail. The original failed run is still visible after recovery.,documentation/KERNEL_DOCUMENTATION_HUB.html#pulse-demo/step-5-6,R1-G04; R1-G06,Not run,,,,,,,Not run,
PULSE-05-07,R1-PULSE-05,Pulse,Schedule published Pulse output,Module journey,P1,Scheduler → Job Runs → Details,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Scheduler → Job Runs → Details | 
Who acts | Authorized auditor/operator | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Authorized auditor/operator
Open: Scheduler → Job Runs → Details
1. Open a completed run and identify job version, requested/completed timestamps, status and producer result reference.
2. Review attempts and ordered audit events such as queued, claimed, dispatched, waiting external and succeeded/failed.
3. Select Download audit and retain the exported file unchanged.
4. Use the Audit file / Verify audit file control to select that file. The browser calculates its hash and verifies its receipt with the server; the full file remains in the browser.
5. If using tamper detection, use a separate edited copy of a demo audit export. Its verification should fail without altering the original server history.
6. Open the job/schedule/queue/backfill/batch Audit history where offered to connect the approval and operational actions to execution.
Screen 17Run details, producer reference and audit verificationExisting application recorded test · example records may differ from your tenant · click to enlarge
• A successful scheduler run must have its producer outcome explained.
• Choose an actual exported audit file; the screenshot has no file selected.
Expected result
The authorized user can trace who created/reviewed/published the definition, what version ran, what happened at each attempt and how the output reference is preserved.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The authorized user can trace who created/reviewed/published the definition, what version ran, what happened at each attempt and how the output reference is preserved.",documentation/KERNEL_DOCUMENTATION_HUB.html#pulse-demo/step-5-7,R1-G04; R1-G06,Not run,,,,,,,Not run,
PULSE-EX-01,R1-PULSE-06,Pulse,Exception / recovery,Exception / recovery,P1,Template preview shows sample placeholders,Use a published authorized dataset with a stable key and a controlled fictional record such as CASE1001. Prepare related rows if the template uses repeats. Select a maker and independent checker. For output-only demonstrations use clearly fictional addresses; for actual sending use an authorized controlled recipient and configured live transport.,"1. Prepare a disposable record exhibiting this condition: Template preview shows sample placeholders.
2. Check saved dataset binding and current-record preview mode.
3. Reopen the affected record and its history; verify: Canvas examples do not establish actual runtime substitution.
4. Record actual outcome and supporting record/version or denial evidence.",Canvas examples do not establish actual runtime substitution.,documentation/KERNEL_DOCUMENTATION_HUB.html#pulse-manual/decision-guide,R1-G04; R1-G06,Not run,,,,,,,Not run,
PULSE-EX-02,R1-PULSE-06,Pulse,Exception / recovery,Exception / recovery,P1,Wrong or multiple parent records,Use a published authorized dataset with a stable key and a controlled fictional record such as CASE1001. Prepare related rows if the template uses repeats. Select a maker and independent checker. For output-only demonstrations use clearly fictional addresses; for actual sending use an authorized controlled recipient and configured live transport.,"1. Prepare a disposable record exhibiting this condition: Wrong or multiple parent records.
2. Check unique key and exact record selection.
3. Reopen the affected record and its history; verify: Resolve ambiguity; do not silently choose the first row.
4. Record actual outcome and supporting record/version or denial evidence.",Resolve ambiguity; do not silently choose the first row.,documentation/KERNEL_DOCUMENTATION_HUB.html#pulse-manual/decision-guide,R1-G04; R1-G06,Not run,,,,,,,Not run,
PULSE-EX-03,R1-PULSE-06,Pulse,Exception / recovery,Exception / recovery,P1,Letter clips after one page,Use a published authorized dataset with a stable key and a controlled fictional record such as CASE1001. Prepare related rows if the template uses repeats. Select a maker and independent checker. For output-only demonstrations use clearly fictional addresses; for actual sending use an authorized controlled recipient and configured live transport.,"1. Prepare a disposable record exhibiting this condition: Letter clips after one page.
2. Inspect page settings, repeat layout and generated PDF.
3. Reopen the affected record and its history; verify: Preview the multi-record/multi-page case before independent review.
4. Record actual outcome and supporting record/version or denial evidence.",Preview the multi-record/multi-page case before independent review.,documentation/KERNEL_DOCUMENTATION_HUB.html#pulse-manual/decision-guide,R1-G04; R1-G06,Not run,,,,,,,Not run,
PULSE-EX-04,R1-PULSE-06,Pulse,Exception / recovery,Exception / recovery,P1,Preview is queued,Use a published authorized dataset with a stable key and a controlled fictional record such as CASE1001. Prepare related rows if the template uses repeats. Select a maker and independent checker. For output-only demonstrations use clearly fictional addresses; for actual sending use an authorized controlled recipient and configured live transport.,"1. Prepare a disposable record exhibiting this condition: Preview is queued.
2. Inspect render worker and returned preview reference.
3. Reopen the affected record and its history; verify: Wait/check the existing request rather than producing duplicate render work.
4. Record actual outcome and supporting record/version or denial evidence.",Wait/check the existing request rather than producing duplicate render work.,documentation/KERNEL_DOCUMENTATION_HUB.html#pulse-manual/decision-guide,R1-G04; R1-G06,Not run,,,,,,,Not run,
PULSE-EX-05,R1-PULSE-06,Pulse,Exception / recovery,Exception / recovery,P1,Email not received,Use a published authorized dataset with a stable key and a controlled fictional record such as CASE1001. Prepare related rows if the template uses repeats. Select a maker and independent checker. For output-only demonstrations use clearly fictional addresses; for actual sending use an authorized controlled recipient and configured live transport.,"1. Prepare a disposable record exhibiting this condition: Email not received.
2. Identify generation, local capture and live provider stages.
3. Reopen the affected record and its history; verify: Only the relevant delivery lifecycle can establish sending/delivery.
4. Record actual outcome and supporting record/version or denial evidence.",Only the relevant delivery lifecycle can establish sending/delivery.,documentation/KERNEL_DOCUMENTATION_HUB.html#pulse-manual/decision-guide,R1-G04; R1-G06,Not run,,,,,,,Not run,
VISTA-01-01,R1-VISTA-01,Vista,Prepare the source and reviewed datasets,Module journey,P1,Vista → Sources & datasets → Available Datasets → Connections → New connection,"Prepare two eligible identities for independent review, a registered/testable source connection, permitted source fields and a small synthetic dataset. Use the supplied service-record sample for explanation; create records through the supported source flow rather than assuming the examples already exist in Azure.","Before you act | Required context | 
Screen / entry | Vista → Sources & datasets → Available Datasets → Connections → New connection | 
Who acts | Maker | 
You need | Prepare two eligible identities for independent review, a registered/testable source connection, permitted source fields and a small synthetic dataset. Use the supplied service-record sample for explanation; create records through the supported source flow rather than assuming the examples already exist in Azure. | 
Steps and field guidance
Who: Maker
Open: Vista → Sources & datasets → Available Datasets → Connections → New connection
1. Enter Connection name and Connection code. Choose the approved HTTPS endpoint that returns your synthetic records as JSON. Do not copy an old screenshot endpoint as an environment configuration.
2. Choose authentication: Public API, Bearer token reference, API key header reference, or Username and password reference. Enter only the configured private credential reference; for an API key, also specify the header name.
3. Set JSON row path to the array location, for example data.records. Leave it blank for a root JSON array.
4. Set Maximum response rows and Timeout in seconds. For this small demo, 100 rows and 15 seconds are sufficient when allowed.
5. For synthetic public reference data choose the corresponding Row scope. For tenant-specific business data choose tenant matching and the actual Tenant ID field. Do not use public scope to bypass tenant filtering.
6. Expand Data access policy when your administrator has supplied the registered resource/permission requirements.
7. Select Save connection draft. On its grid row select Test & discover. If queued, use Check test result until it reaches a usable READY result. Inspect discovered fields, types, row count and the latest snapshot.
Screen 1Connection definition and authentication referencesExisting application recorded test · example records may differ from your tenant · click to enlarge
• The external endpoint and credential reference belong to the connection.
• The screenshot uses an earlier test API; use your approved demo endpoint.
Expected result
The connection draft has a successful field-discovery result for its current revision. Failure, timeout or an empty field contract is shown explicitly.
This self-service flow is an approved-host HTTPS JSON connector. The inspected UI supports a maximum of 500 response rows and 2 MB, with 1–30 second timeouts. It uses an explicit source snapshot. It is not an arbitrary SQL connection browser or a promise of unlimited provider/pagination support.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The connection draft has a successful field-discovery result for its current revision. Failure, timeout or an empty field contract is shown explicitly.",documentation/KERNEL_DOCUMENTATION_HUB.html#vista-demo/step-1-1,R1-G06,Not run,,,,,,,Not run,
VISTA-01-02,R1-VISTA-01,Vista,Prepare the source and reviewed datasets,Module journey,P1,Connections → the same record row,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Connections → the same record row | 
Who acts | Maker → independent Checker → authorized Publisher | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Maker → independent Checker → authorized Publisher
Open: Connections → the same record row
1. Maker completes Test & discover for the saved revision, then selects Submit for review. Provide a meaningful reason.
2. Checker opens the same connection, inspects endpoint, authentication reference, tenant scope and selected fields, then runs its own Test & discover.
3. After its current successful test, Checker chooses Approve or Return on the row. Returned changes go back to the author for correction and another test/review.
4. The authorized publisher selects Publish after approval. Refresh the source setup screen.
5. For a published connection, verify Refresh snapshot and inspect the result. This refresh changes the source data snapshot; it does not silently edit approved source field definitions.
Expected result
The connection becomes published and eligible for source-definition selection. A fresh successful test is required for the revision being submitted/reviewed.
Connection test eligibility is time-limited (30 minutes in the inspected implementation). A changed revision, expired test or changed authorization requires a new test. Publication of a connection does not create a dataset or report.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The connection becomes published and eligible for source-definition selection. A fresh successful test is required for the revision being submitted/reviewed.,documentation/KERNEL_DOCUMENTATION_HUB.html#vista-demo/step-1-2,R1-G06,Not run,,,,,,,Not run,
VISTA-01-03,R1-VISTA-01,Vista,Prepare the source and reviewed datasets,Module journey,P1,Vista → Sources & datasets → Source definitions → New source,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Vista → Sources & datasets → Source definitions → New source | 
Who acts | Maker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Maker
Open: Vista → Sources & datasets → Source definitions → New source
1. Enter Source name: Service records and Source code: DEMO_SERVICE_SOURCE, with your unique suffix.
2. Select the approved published connection from the connection selector.
3. Select the discovered fields needed by the demo, including record_id and the numeric amount. Include the contact fields only when the intended readers are authorized to use them.
4. Save source draft. Preview the saved source and inspect its current rows and field contract.
5. Submit for review. The independent Checker opens the same source row, performs its own preview, checks field exposure and approves or returns.
6. Publish the approved source. Refresh Datasets or the Studio source-selection step.
7. Repeat for the optional Service line items source using its corresponding approved connection/registered source.
Screen 2Source Definitions is the named-source masterExisting application recorded test · example records may differ from your tenant · click to enlarge
• Connections, Source Definitions and Datasets are separate tabs.
• New source defines a reusable field set from a connection; Create dataset consumes a published source.
Expected result
Service records appears as a published source. Its name and field contract are available to dataset builders with the correct scope.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Service records appears as a published source. Its name and field contract are available to dataset builders with the correct scope.,documentation/KERNEL_DOCUMENTATION_HUB.html#vista-demo/step-1-3,R1-G06,Not run,,,,,,,Not run,
VISTA-01-04,R1-VISTA-01,Vista,Prepare the source and reviewed datasets,Module journey,P1,Vista → Sources & datasets → Datasets → New dataset,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Vista → Sources & datasets → Datasets → New dataset | 
Who acts | Maker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Maker
Open: Vista → Sources & datasets → Datasets → New dataset
1. Enter Dataset name: Service review dataset and Dataset code: DEMO_SERVICE_DATA.
2. Choose Select fields from one source and select Service records.
3. Select record_id, recipient_name, recipient_address, organisation_name, reference, correspondence_date, recipient_email, region, status and amount. Check the actual types, especially numeric amount.
4. Save dataset draft. Open Preview from the saved row. Verify CASE1001 and its authorized values; an empty result must be understood rather than filled with invented records.
5. Return to the dataset row and choose Submit for review.
6. Checker uses its own profile and Preview on the same saved revision, inspects fields/data/scope, then Approve or Return.
7. Publish the approved dataset. It is now eligible for the report/Pulse Studio setup. Prepare and publish Service line items similarly if using repeated content.
Expected result
A published dataset with a stable field contract is selectable in Studio. Merely saving a draft does not expose it for general report building.
Dataset preview shows up to 50 current authorized rows. Its review eligibility belongs to the saved revision and selected profile and lasts 15 minutes in the inspected implementation. Changing the draft or profile, or waiting past expiry, requires another preview. The independent Checker must obtain its own preview.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",A published dataset with a stable field contract is selectable in Studio. Merely saving a draft does not expose it for general report building.,documentation/KERNEL_DOCUMENTATION_HUB.html#vista-demo/step-1-4,R1-G06,Not run,,,,,,,Not run,
VISTA-01-05,R1-VISTA-01,Vista,Prepare the source and reviewed datasets,Module journey,P1,"New dataset → Dataset structure → Model sources, joins and calculations","Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | New dataset → Dataset structure → Model sources, joins and calculations | 
Who acts | Maker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Maker
Open: New dataset → Dataset structure → Model sources, joins and calculations
1. Choose the primary source with alias main. Add a second source with alias lookup or items, and select the required input fields.
2. Join compatible keys. For the example, main.record_id joins items.case_id. Use LEFT to retain a primary record without items, or INNER to keep matches only.
3. Add selected fields as outputs. Give outputs distinct lowercase names. Add a calculated field, such as line_amount × a numeric constant, using the expression controls.
4. Add a filter only when it expresses the intended business subset, such as status equals OPEN. Explain how it changes the totals.
5. Preview the model. Inspect duplicate keys and row multiplication before interpreting counts or sums. Do not sum parent amount after a one-to-many join without accounting for repeated parent rows.
6. Save, preview, independently review and publish the modelled dataset exactly as for the simple dataset.
Screen 3Dataset model: selected sources and fieldsExisting application recorded test · example records may differ from your tenant · click to enlarge
• The model uses compatible registered field types and source versions.
• Each additional source needs a join; all outputs are explicit.
Screen 4Checker previews the saved dataset modelExisting application recorded test · example records may differ from your tenant · click to enlarge
• This earlier recorded test shows joined current data.
• Review actual values and cardinality; the screenshot is not the Service review example.
Model feature | Inspected support | 
Sources / joins | 1–3 sources; INNER and LEFT joins; compatible key types | 
Outputs / filters | 1–40 named outputs; up to 12 boolean filters | 
Numeric expressions | Add, subtract, multiply, divide, round | 
Text/date expressions | Uppercase, lowercase, trim, concatenate, year from a date | 
Conditions / nulls | Comparisons, contains, AND/OR/NOT, is-empty, fallback when empty | 
Runtime behavior | Null join keys do not match; division by zero produces empty output; current access still applies | 
For the simple user walkthrough, keep the primary dataset one row per case. Use Pulse’s related-record collections for line items. A modelled dataset is the supported way to supply a report’s one primary dataset from several sources.
Check before continuing: The saved dataset model has the intended selected fields, types, joins and calculated values. Its current preview and independent decision apply to that exact revision.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The saved dataset model has the intended selected fields, types, joins and calculated values. Its current preview and independent decision apply to that exact revision.",documentation/KERNEL_DOCUMENTATION_HUB.html#vista-demo/step-1-5,R1-G06,Not run,,,,,,,Not run,
VISTA-02-01,R1-VISTA-02,Vista,Create and publish a report,Module journey,P1,"New report, New dashboard, Create email template or Create letter template","Prepare two eligible identities for independent review, a registered/testable source connection, permitted source fields and a small synthetic dataset. Use the supplied service-record sample for explanation; create records through the supported source flow rather than assuming the examples already exist in Azure.","Before you act | Required context | 
Screen / entry | New report, New dashboard, Create email template or Create letter template | 
Who acts | Maker | 
You need | Prepare two eligible identities for independent review, a registered/testable source connection, permitted source fields and a small synthetic dataset. Use the supplied service-record sample for explanation; create records through the supported source flow rather than assuming the examples already exist in Azure. | 
Steps and field guidance
Who: Maker
Open: New report, New dashboard, Create email template or Create letter template
1. Sources: Define or choose sources. Select the published source(s) used by your dataset. Define source opens the source master when authorized.
2. Datasets: Build or choose datasets that match those selected sources. Build dataset opens the dataset master. Newly created items become selectable after review and publication.
3. Basic details: Type the artifact’s name and code. Verify the chosen source/dataset summary.
4. Studio: Select Open Studio. Start from a blank canvas, then optionally choose a template/layout from the toolbar.
Screen 5First select the sourcesExisting application recorded test · example records may differ from your tenant · click to enlarge
• Selection reflects current profile access.
• The same setup pattern is used by Vista and Pulse.
Screen 6Then name the artifact before opening StudioExisting application recorded test · example records may differ from your tenant · click to enlarge
• Basic details retain the source/dataset selection.
• Open Studio begins composition; it does not publish anything.
A report and Pulse template use one primary dataset. A modelled dataset can combine sources. Dashboard setup can select multiple datasets, but its tiles come from published report visuals. Selecting a source alone does not supply a report layout.
Check before continuing: The artifact has the intended source(s), eligible dataset(s), name and basic details before Studio opens. The selected context is carried into the saved draft.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The artifact has the intended source(s), eligible dataset(s), name and basic details before Studio opens. The selected context is carried into the saved draft.",documentation/KERNEL_DOCUMENTATION_HUB.html#vista-demo/step-2-1,R1-G06,Not run,,,,,,,Not run,
VISTA-02-02,R1-VISTA-02,Vista,Create and publish a report,Module journey,P1,Vista → Reports & visuals → Report Studio → New report,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Vista → Reports & visuals → Report Studio → New report | 
Who acts | Maker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Maker
Open: Vista → Reports & visuals → Report Studio → New report
1. Complete the shared setup using Service records → Service review dataset → Service operations report / DEMO_SERVICE_REPORT.
2. Open the blank canvas. Choose an optional layout from the toolbar, or add individual components.
3. Add a Heading: Service operations review. Add a short Text block describing scope and date.
4. Add a Summary Card named Total records using count. Add another card for Total amount using sum of amount.
5. Add a Chart: Columns or Horizontal bars. Group by region and aggregate amount by sum.
6. Add a Data Table with record_id, recipient_name, region, status and amount. Set useful widths and number formatting.
7. In Page settings choose paper/orientation/margins; keep the report readable at its actual output size. Use Page Break when a new section should start on a new page.
8. Check the Data tab for selected columns, placeholder mappings and any layout problems. Save draft with a clear reason.
Screen 7Report Studio starts with a blank compositionExisting application recorded test · example records may differ from your tenant · click to enlarge
• Components are on the left; selected block and page settings are on the right.
• Dataset selection stays visible; Save draft creates the version to preview and review.
Expected result
The saved report contains a real dataset reference and named visual blocks. For the full four-record synthetic result, count is 4 and sum is 4000; confirm the actual preview scope before using those totals.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The saved report contains a real dataset reference and named visual blocks. For the full four-record synthetic result, count is 4 and sum is 4000; confirm the actual preview scope before using those totals.",documentation/KERNEL_DOCUMENTATION_HUB.html#vista-demo/step-2-2,R1-G06,Not run,,,,,,,Not run,
VISTA-02-03,R1-VISTA-02,Vista,Create and publish a report,Module journey,P1,the saved report draft in Report Studio and select the component to configure.,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | the saved report draft in Report Studio and select the component to configure. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
1. Open the saved report draft in Report Studio and select the component to configure.
2. Choose a supported component or chart type from the tool reference below. Bind fields of the expected types and configure aggregation, grouping and formatting.
3. For a pivot, choose the row field, column field and numeric measure. For expressions, use the offered expression controls and inspect empty values and zero denominators.
4. Save the draft, render its saved preview with current authorized data and compare visible values with the dataset. Correct any validation or layout problem before independent review.
Tool | Short user walkthrough | 
Charts | Switch the same region/amount visual between bars, columns, line, area, donut and pie where meaningful | 
Stacked columns | Use region as category and status as the series field | 
Scatter plot | Choose two genuinely numeric fields; do not force a text status into an axis | 
Pivot table | Rows = region, columns = status, measure = sum amount | 
Calculated measures | Use the offered numeric expression controls and check empty/zero-denominator behavior | 
Repeating section | Choose supported dataset fields to repeat in the body | 
Formatting | Titles, alignment, section placement, number/currency/percent formatting, paper and margins | 
Editing | Select, move, duplicate/delete supported blocks, Undo/Redo and focus mode | 
Draft recovery | Restore an offered working copy, then explicitly save and preview the resulting revision | 
The inspected chart styles are horizontal bars, columns, line, area, donut, pie, stacked columns and scatter. Use the chart type that explains the data. A meaningful three-visual report is a stronger demo than cycling through every option.
Working-copy recovery is not publication and is not a substitute for Save draft. A restored layout must still pass current validation, current-data preview and independent review. Do not claim unsupported expressions, unlimited blocks or arbitrary scripting.
Check before continuing: The saved report preview renders the configured charts, expressions and pivots with current authorized values, including the tested empty/zero cases.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The saved report preview renders the configured charts, expressions and pivots with current authorized values, including the tested empty/zero cases.",documentation/KERNEL_DOCUMENTATION_HUB.html#vista-demo/step-2-3,R1-G06,Not run,,,,,,,Not run,
VISTA-02-04,R1-VISTA-02,Vista,Create and publish a report,Module journey,P1,Report Studio → saved report / Reports & reviews,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Report Studio → saved report / Reports & reviews | 
Who acts | Maker → independent Checker → Publisher | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Maker → independent Checker → Publisher
Open: Report Studio → saved report / Reports & reviews
1. Save all edits. Choose Dataset Preview for the saved report. Wait for current authorized rows to load and inspect the rendered components, not just the field names.
2. Confirm the report revision, dataset contract and displayed scope. Correct any missing field, unavailable source or layout problem; save and preview again.
3. Choose Submit for review on the report’s row or the corresponding Studio action. Provide the requested reason and confirm.
4. Checker opens that report from the catalog/row, previews the same saved revision with its own current access, then selects Approve or Return.
5. After approval, an authorized publisher selects Publish and confirms the reason. Verify the catalog’s published version.
6. Show a returned draft only if prearranged: the author corrects it, saves, previews and resubmits through one new independent decision.
Screen 8Saved report preview with current dataset rowsExisting application recorded test · example records may differ from your tenant · click to enlarge
• The preview identifies current authorized data and its bounded row count.
• Changing the saved revision invalidates review eligibility.
Expected result
The report is PUBLISHED and available as a dashboard visual source and Scheduler report artifact.
The Report Catalog’s lightweight preview can show up to 10 current rows. It is useful for inspection, but use the saved-revision Studio preview required for submission/approval. Design examples or sample rows do not establish review eligibility. The workflow is Draft → one independent review → Approved → Publish, not several independent approval levels.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The report is PUBLISHED and available as a dashboard visual source and Scheduler report artifact.,documentation/KERNEL_DOCUMENTATION_HUB.html#vista-demo/step-2-4,R1-G06,Not run,,,,,,,Not run,
VISTA-02-05,R1-VISTA-02,Vista,Create and publish a report,Module journey,P1,Published report → Run Report; then Run Output / Runs,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Published report → Run Report; then Run Output / Runs | 
Who acts | Authorized report runner | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Authorized report runner
Open: Published report → Run Report; then Run Output / Runs
1. Choose the published report/version. Select Run Report and provide the execution reason.
2. Wait for the actual run to complete. Open its Run Output; record the run reference and completion status.
3. Compare the output’s dataset/columns and key values with the intended source snapshot and profile scope. Preview limits and full-run limits can differ; do not infer totals from an incomplete preview.
4. Use CSV, Excel or Print/PDF when permitted. Check table headings, numeric formatting, page boundaries and footer/content placement.
5. Keep the completed run reference for comparison with the scheduled run later.
Expected result
A completed output belongs to the published version and the authorized execution. Viewing the designer or obtaining a preview does not itself create this run.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",A completed output belongs to the published version and the authorized execution. Viewing the designer or obtaining a preview does not itself create this run.,documentation/KERNEL_DOCUMENTATION_HUB.html#vista-demo/step-2-5,R1-G06,Not run,,,,,,,Not run,
VISTA-03-01,R1-VISTA-03,Vista,Build and publish a dashboard,Module journey,P1,Vista → Dashboard catalog → Dashboards → New dashboard,"Prepare two eligible identities for independent review, a registered/testable source connection, permitted source fields and a small synthetic dataset. Use the supplied service-record sample for explanation; create records through the supported source flow rather than assuming the examples already exist in Azure.","Before you act | Required context | 
Screen / entry | Vista → Dashboard catalog → Dashboards → New dashboard | 
Who acts | Maker | 
You need | Prepare two eligible identities for independent review, a registered/testable source connection, permitted source fields and a small synthetic dataset. Use the supplied service-record sample for explanation; create records through the supported source flow rather than assuming the examples already exist in Azure. | 
Steps and field guidance
Who: Maker
Open: Vista → Dashboard catalog → Dashboards → New dashboard
1. Complete Sources → Datasets → Basic details using Service operations dashboard / DEMO_SERVICE_DASH. Select every dataset whose published report visuals you intend to add.
2. In Published report visuals, find Service operations report. Add its Total records KPI, Total amount KPI, Region chart and Detail table as separate tiles.
3. Use Arrange tiles for Balanced, Featured lead visual or Compact. Adjust each tile’s title, width and order. The grid has 12 columns and the inspected editor supports up to 8 tiles.
4. Save draft. Use the saved dashboard Preview to load current authorized rows for each pinned report visual. Verify every tile.
5. Maker submits the saved revision for review. Checker independently previews it and approves or returns from the dashboard record/row.
6. Publish the approved dashboard. Use Refresh Dashboard to produce a live snapshot and inspect the date/version and individual tile results.
7. Open a tile’s available drill-down and verify Print/PDF if permitted.
Screen 9Dashboard composition uses published report visualsExisting application recorded test · example records may differ from your tenant · click to enlarge
• A dashboard can combine visuals using different datasets.
• Each tile retains the exact approved report version; the blank canvas is expected before adding visuals.
Expected result
The dashboard is PUBLISHED with all intended tiles available. It becomes selectable in the Scheduler dashboard operation.
A dataset alone is not a dashboard tile. Publish a report containing the desired KPI/chart/table first. A newly published report version does not silently replace a tile’s pinned report version. An unavailable tile is visible as a problem; do not present a partial dashboard as complete.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The dashboard is PUBLISHED with all intended tiles available. It becomes selectable in the Scheduler dashboard operation.,documentation/KERNEL_DOCUMENTATION_HUB.html#vista-demo/step-3-1,R1-G06,Not run,,,,,,,Not run,
VISTA-04-01,R1-VISTA-04,Vista,Schedule published Vista output,Module journey,P1,Scheduler → Job Definitions → New job,"Prepare two eligible identities for independent review, a registered/testable source connection, permitted source fields and a small synthetic dataset. Use the supplied service-record sample for explanation; create records through the supported source flow rather than assuming the examples already exist in Azure.","Before you act | Required context | 
Screen / entry | Scheduler → Job Definitions → New job | 
Who acts | Scheduler Maker | 
You need | Prepare two eligible identities for independent review, a registered/testable source connection, permitted source fields and a small synthetic dataset. Use the supplied service-record sample for explanation; create records through the supported source flow rather than assuming the examples already exist in Azure. | 
Steps and field guidance
Who: Scheduler Maker
Open: Scheduler → Job Definitions → New job
1. Choose Business operation: Run published Vista report. Select the approved Run as execution identity.
2. Enter Job name: Service report generation and Job code: DEMO_REPORT_JOB. Add a useful description.
3. In Published content choose Service operations report and its published version by name. The application fills its identity, version, revision and content hash.
4. Add Reason as a text Value: Reference-data setup: generate the approved service operations report. Use the offered contract inputs; do not invent reportId/version values.
5. Set Timeout to 300 seconds for the walkthrough if appropriate. Start with Maximum attempts 1 and overlap policy Wait in queue. Verify retry tuning separately.
6. Save draft. Select Preview on the saved job row. Inspect the operation, execution context, resolved values and pinned artifact.
7. Return to the row and Submit for review. Checker independently previews the same revision, then Approve or Return. Publish the approved job version.
Screen 10Job inputs bind a named published reportExisting application recorded test · example records may differ from your tenant · click to enlarge
• The selector supplies the version and content hash automatically.
• Execution policy is saved with the job definition.
Screen 11Job preview resolves inputs without executing the business operationExisting application recorded test · example records may differ from your tenant · click to enlarge
• Preview establishes current saved-definition eligibility.
• It does not generate the report; an actual run comes later.
Expected result
A published report job is available to Run a job, Schedules and compatible batch steps.
A job’s saved artifact reference is pinned. Publishing report version 2 does not make this job use version 2. Change the job through its supported new-version/review/publication flow and then update dependent schedules/batches explicitly.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","A published report job is available to Run a job, Schedules and compatible batch steps.",documentation/KERNEL_DOCUMENTATION_HUB.html#vista-demo/step-4-1,R1-G06,Not run,,,,,,,Not run,
VISTA-04-02,R1-VISTA-04,Vista,Schedule published Vista output,Module journey,P1,Job definition → Inputs,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Job definition → Inputs | 
Who acts | Scheduler Maker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Scheduler Maker
Open: Job definition → Inputs
1. Choose an input permitted by the selected operation’s schema. For example, bind the email job’s recipient to the authorized primary dataset’s recipient_email.
2. Set Input source to Dataset field. Select the published dataset, value field recipient_email, unique key field record_id and exact record CASE1001.
3. Add the input and inspect the resulting input grid. Keep Record key consistent with the Pulse template’s intended parent record.
4. Save and Preview. Confirm the currently resolved value and its dataset version/contract. Submit/review/publish the changed definition as required.
5. At execution the binding is read and validated again. Verify a changed value only using a controlled source update followed by the required snapshot refresh; then compare the actual output.
Expected result
The job reads a current authorized value for one explicitly selected record. Missing access, missing/ambiguous keys or incompatible values fail rather than silently using an unrelated record.
Dataset field binding is not “run once per every dataset row.” The inspected input model selects one record per binding. Do not claim bulk-recipient fan-out, arbitrary output-to-input piping or a generic ETL loop. Use a registered business operation for any additional bulk behavior.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The job reads a current authorized value for one explicitly selected record. Missing access, missing/ambiguous keys or incompatible values fail rather than silently using an unrelated record.",documentation/KERNEL_DOCUMENTATION_HUB.html#vista-demo/step-4-2,R1-G06,Not run,,,,,,,Not run,
VISTA-04-03,R1-VISTA-04,Vista,Schedule published Vista output,Module journey,P1,Scheduler → Job Runs → Run a job,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Scheduler → Job Runs → Run a job | 
Who acts | Authorized Scheduler operator | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Authorized Scheduler operator
Open: Scheduler → Job Runs → Run a job
1. Select the published Service report generation job. Preview current inputs, provide the execution reason and select Queue run. Record the run reference.
2. Refresh the run. Follow Queued → Claimed/Running → Waiting external where applicable → Succeeded or an explicit failure.
3. Open Details. Inspect the exact job version, attempt information, execution timestamps and Producer result reference.
4. Repeat for the dashboard, email and letter jobs, one at a time for the user walkthrough.
5. For each producer result, open the appropriate authorized Vista/Pulse output screen or access-controlled result view. Compare it with the manual output and intended case.
6. Record actual outcomes in LIVE_DEMO_CHECKLIST.csv. Do not mark a queued/accepted job as a successful generated output.
Job | Required success evidence | Extra check | 
Report | Scheduler SUCCEEDED + completed report result reference | Expected dataset scope, values and published report version | 
Dashboard | Scheduler SUCCEEDED + completed snapshot | Every tile available; PARTIAL is not success | 
Email | Scheduler SUCCEEDED + READY generated-email reference | Correct record, sender/recipient in file; no claim of send | 
Letter | Scheduler SUCCEEDED + READY letter/PDF reference | Correct recipient/reference and pagination | 
Scheduled work can run as a service identity different from the operator. Producer output lists are access-controlled and may be requester-scoped. A result absent from the operator’s personal Generated Emails/Rendered letters list is not proof that no output exists. Use the authorized result access path and the scheduler’s recorded producer reference; do not broaden permissions just to expose another identity’s output.
Expected result
All four actual executions have a result reference and a verified output. Rehearse these before enabling a recurring schedule.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",All four actual executions have a result reference and a verified output. Rehearse these before enabling a recurring schedule.,documentation/KERNEL_DOCUMENTATION_HUB.html#vista-demo/step-4-3,R1-G06,Not run,,,,,,,Not run,
VISTA-04-04,R1-VISTA-04,Vista,Schedule published Vista output,Module journey,P1,Scheduler → Schedules → New schedule,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Scheduler → Schedules → New schedule | 
Who acts | Scheduler Maker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Scheduler Maker
Open: Scheduler → Schedules → New schedule
1. Select the published job version. Enter name/code, for example Service report weekday schedule / DEMO_REPORT_SCHEDULE.
2. For the first live execution choose Run once and a future execution time with enough time to complete review. Enter the UTC instant in the field explicitly labelled UTC.
3. Choose the display/calendar Time zone. Inspect both UTC and local time in Preview rather than relying on the browser’s timezone.
4. For repetition choose Fixed elapsed interval with a UTC anchor and interval seconds, or Calendar schedule with a five-field cron expression.
5. Optionally select a published Business calendar. It pins that calendar version and constrains the schedule to its allowed dates/windows.
6. Choose the missed-execution policy and limits. Save draft, Preview upcoming dates and current input bindings, then Submit for review.
7. Checker performs its own current Preview and Approve or Return. An authorized publisher uses Publish and enable when the approved revision has a fresh preview.
8. Open Job Runs after the occurrence. Verify the schedule’s run and producer result, then pause or retire the demo schedule after use.
Screen 12Schedule timing, calendar and missed-execution behaviorExisting application recorded test · example records may differ from your tenant · click to enlarge
• A schedule pins an exact published job version.
• Saving a draft does not enable execution.
Trigger | Example | Use | 
Run once | A chosen future UTC instant | One client-demo execution | 
Fixed elapsed interval | Anchor in UTC; every 3600 seconds | Elapsed hourly cadence independent of local DST | 
Calendar schedule | 0 9 * * 1-5 in the chosen timezone | 09:00 on weekdays | 
Calendar schedule | 0 9 * * 1 | Monday at 09:00 | 
Calendar schedule | 0 9 1 * * | First day of each month at 09:00 | 
Create separate schedules for the email, letter and dashboard jobs using the same procedure when they need independent timing. A schedule is a job trigger; the inspected schedule selector does not establish timer-triggered batch execution. Verify batch execution through Batches, as described later.
Check before continuing: The saved reviewed schedule references the intended published job version, timezone and calendar. Its upcoming occurrences and missed-execution behavior match the requested timing.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The saved reviewed schedule references the intended published job version, timezone and calendar. Its upcoming occurrences and missed-execution behavior match the requested timing.",documentation/KERNEL_DOCUMENTATION_HUB.html#vista-demo/step-4-4,R1-G06,Not run,,,,,,,Not run,
VISTA-04-05,R1-VISTA-04,Vista,Schedule published Vista output,Module journey,P1,"Job Runs, Schedules and Job Definitions → eligible row actions","Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Job Runs, Schedules and Job Definitions → eligible row actions | 
Who acts | Authorized operator | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
1. Open the existing run, schedule or job and inspect its current status and last producer result.
2. Choose the single action that matches your need from the table below. Check the effect on already accepted work before confirming.
3. For a rerun, preview current inputs and supply the reason; for schedule resumption, inspect upcoming dates and missed-execution behavior.
4. Confirm the eligible action once. Refresh the originating record, retain the new receipt/reference and compare it with the original history.
Who: Authorized operator
Open: Job Runs, Schedules and Job Definitions → eligible row actions
Action | Procedure | Important effect | 
Rerun a completed/failed eligible run | Open run → Rerun → Preview current inputs → reason → Queue run | New linked run; same approved job version; current data may differ | 
Cancel queued run | Select Cancel queued run and confirm the reason | Only eligible queued work; not a rollback of accepted external work | 
Pause schedule | Open eligible schedule row → Pause → reason | Stops future scheduling; already accepted/queued runs remain separate | 
Resume schedule | Preview upcoming dates/current inputs, then Resume when eligible | Missed-execution policy governs the resumption | 
Retire schedule | Use its offered retirement action and reason | Retains historical occurrences/runs | 
Retire job | Use the job’s permitted retirement action | Stops new runs for the retired job; accepted work/history are retained | 
Create new job version | Branch/edit the supported draft → save → preview → review → publish | Dependents must explicitly select the new published version | 
Do not rerun uncertain external effects merely because the screen timed out. Reconciliation-required runs block automatic rerun. Changing a record to inactive or retired is not a universal cancellation or deletion mechanism.
Expected result
Every operator action has a reason and a retained audit trail. The original failed run is still visible after recovery.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Every operator action has a reason and a retained audit trail. The original failed run is still visible after recovery.,documentation/KERNEL_DOCUMENTATION_HUB.html#vista-demo/step-4-5,R1-G06,Not run,,,,,,,Not run,
VISTA-04-06,R1-VISTA-04,Vista,Schedule published Vista output,Module journey,P1,Scheduler → Job Runs → Details,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Scheduler → Job Runs → Details | 
Who acts | Authorized auditor/operator | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Authorized auditor/operator
Open: Scheduler → Job Runs → Details
1. Open a completed run and identify job version, requested/completed timestamps, status and producer result reference.
2. Review attempts and ordered audit events such as queued, claimed, dispatched, waiting external and succeeded/failed.
3. Select Download audit and retain the exported file unchanged.
4. Use the Audit file / Verify audit file control to select that file. The browser calculates its hash and verifies its receipt with the server; the full file remains in the browser.
5. If using tamper detection, use a separate edited copy of a demo audit export. Its verification should fail without altering the original server history.
6. Open the job/schedule/queue/backfill/batch Audit history where offered to connect the approval and operational actions to execution.
Screen 13Run details, producer reference and audit verificationExisting application recorded test · example records may differ from your tenant · click to enlarge
• A successful scheduler run must have its producer outcome explained.
• Choose an actual exported audit file; the screenshot has no file selected.
Expected result
The authorized user can trace who created/reviewed/published the definition, what version ran, what happened at each attempt and how the output reference is preserved.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The authorized user can trace who created/reviewed/published the definition, what version ran, what happened at each attempt and how the output reference is preserved.",documentation/KERNEL_DOCUMENTATION_HUB.html#vista-demo/step-4-6,R1-G06,Not run,,,,,,,Not run,
VISTA-EX-01,R1-VISTA-05,Vista,Exception / recovery,Exception / recovery,P1,New dataset button is missing,"Prepare two eligible identities for independent review, a registered/testable source connection, permitted source fields and a small synthetic dataset. Use the supplied service-record sample for explanation; create records through the supported source flow rather than assuming the examples already exist in Azure.","1. Prepare a disposable record exhibiting this condition: New dataset button is missing.
2. Check create permission and selected context.
3. Reopen the affected record and its history; verify: Screen read access does not grant dataset creation.
4. Record actual outcome and supporting record/version or denial evidence.",Screen read access does not grant dataset creation.,documentation/KERNEL_DOCUMENTATION_HUB.html#vista-manual/decision-guide,R1-G06,Not run,,,,,,,Not run,
VISTA-EX-02,R1-VISTA-05,Vista,Exception / recovery,Exception / recovery,P1,Preview has more rows after a join,"Prepare two eligible identities for independent review, a registered/testable source connection, permitted source fields and a small synthetic dataset. Use the supplied service-record sample for explanation; create records through the supported source flow rather than assuming the examples already exist in Azure.","1. Prepare a disposable record exhibiting this condition: Preview has more rows after a join.
2. Inspect key uniqueness and join cardinality.
3. Reopen the affected record and its history; verify: One-to-many relationships can multiply rows and totals; correct the model before review.
4. Record actual outcome and supporting record/version or denial evidence.",One-to-many relationships can multiply rows and totals; correct the model before review.,documentation/KERNEL_DOCUMENTATION_HUB.html#vista-manual/decision-guide,R1-G06,Not run,,,,,,,Not run,
VISTA-EX-03,R1-VISTA-05,Vista,Exception / recovery,Exception / recovery,P1,Dataset missing in Studio,"Prepare two eligible identities for independent review, a registered/testable source connection, permitted source fields and a small synthetic dataset. Use the supplied service-record sample for explanation; create records through the supported source flow rather than assuming the examples already exist in Azure.","1. Prepare a disposable record exhibiting this condition: Dataset missing in Studio.
2. Check publication, active source, selected sources and scope.
3. Reopen the affected record and its history; verify: Saving alone is not publication.
4. Record actual outcome and supporting record/version or denial evidence.",Saving alone is not publication.,documentation/KERNEL_DOCUMENTATION_HUB.html#vista-manual/decision-guide,R1-G06,Not run,,,,,,,Not run,
VISTA-EX-04,R1-VISTA-05,Vista,Exception / recovery,Exception / recovery,P1,Submit/approve disabled,"Prepare two eligible identities for independent review, a registered/testable source connection, permitted source fields and a small synthetic dataset. Use the supplied service-record sample for explanation; create records through the supported source flow rather than assuming the examples already exist in Azure.","1. Prepare a disposable record exhibiting this condition: Submit/approve disabled.
2. Check saved revision, preview freshness and actor eligibility.
3. Reopen the affected record and its history; verify: Obtain current preview as the responsible actor; do not reuse an old screenshot.
4. Record actual outcome and supporting record/version or denial evidence.",Obtain current preview as the responsible actor; do not reuse an old screenshot.,documentation/KERNEL_DOCUMENTATION_HUB.html#vista-manual/decision-guide,R1-G06,Not run,,,,,,,Not run,
VISTA-EX-05,R1-VISTA-05,Vista,Exception / recovery,Exception / recovery,P1,Scheduled dashboard is partial,"Prepare two eligible identities for independent review, a registered/testable source connection, permitted source fields and a small synthetic dataset. Use the supplied service-record sample for explanation; create records through the supported source flow rather than assuming the examples already exist in Azure.","1. Prepare a disposable record exhibiting this condition: Scheduled dashboard is partial.
2. Inspect every pinned report tile and its source authorization.
3. Reopen the affected record and its history; verify: Do not count a partially rendered dashboard as complete success.
4. Record actual outcome and supporting record/version or denial evidence.",Do not count a partially rendered dashboard as complete success.,documentation/KERNEL_DOCUMENTATION_HUB.html#vista-manual/decision-guide,R1-G06,Not run,,,,,,,Not run,
SCHEDULER-01-01,R1-SCHEDULER-01,Enterprise Scheduler,"Define, publish and run a job",Module journey,P1,Job Definitions and start a new draft only after the intended business artifact is published.,"Prepare published source connection, Vista report/dashboard and Pulse email/letter templates with reviewed datasets. Use compatible domain and execution identity for batch jobs. Verify the physical worker/queue is available. Use isolated fixtures for failure, pause or capacity demonstrations; do not stop a shared production worker to create a failure.","Before you act | Required context | 
Screen / entry | Job Definitions and start a new draft only after the intended business artifact is published. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Prepare published source connection, Vista report/dashboard and Pulse email/letter templates with reviewed datasets. Use compatible domain and execution identity for batch jobs. Verify the physical worker/queue is available. Use isolated fixtures for failure, pause or capacity demonstrations; do not stop a shared production worker to create a failure. | 
Steps and field guidance
1. Open Job Definitions and start a new draft only after the intended business artifact is published.
2. Select the registered operation that matches the artifact and output in the table below.
3. Confirm the Run as identity can access that artifact and its source data. Continue to the job-definition procedure to save, preview and govern the exact binding.
Content / purpose | Registered business operation | Produced result | 
Source connection | NEXUS_SOURCE_REFRESH_V1 · Refresh published source connection | New authorized source snapshot | 
Vista report | VISTA_REPORT_V1 · Run published Vista report | Published report output | 
Vista dashboard | VISTA_DASHBOARD_V1 · Run published Vista dashboard (registered operation version 2) | Dashboard snapshot with all report tiles checked | 
Pulse email | PULSE_EMAIL_V1 · Generate published Pulse email | Generated email file; sending is separate | 
Pulse letter | PULSE_LETTER_V1 · Generate published Pulse letter | Rendered letter/PDF output | 
Private draft maintenance | VISTA_RECOVERY_CLEANUP_V1 / PULSE_RECOVERY_CLEANUP_V1 | Bounded removal of expired recovery copies; maintenance permission required | 
Published artifact + authorized Run as identity + inputs → reviewed Job Definition → published version → Schedule / Run now / Batch step → worker → owning producer → result reference
A dataset is consumed by a report/template or used for job input binding. It is not automatically a standalone executable job. The source refresh operation refreshes a published connection’s snapshot. Additional external business operations must be registered with a supported input/result contract and permission model before they appear in the selector.
Expected result
The operator can identify which owning module produces the result and which job/schedule/run record coordinates it.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The operator can identify which owning module produces the result and which job/schedule/run record coordinates it.,documentation/KERNEL_DOCUMENTATION_HUB.html#scheduler-demo/step-1-1,R1-G07; R1-G08; R1-G09,Not run,,,,,,,Not run,
SCHEDULER-01-02,R1-SCHEDULER-01,Enterprise Scheduler,"Define, publish and run a job",Module journey,P1,Scheduler → Job Definitions → New job,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Scheduler → Job Definitions → New job | 
Who acts | Scheduler Maker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Scheduler Maker
Open: Scheduler → Job Definitions → New job
1. Choose Business operation: Run published Vista report. Select the approved Run as execution identity.
2. Enter Job name: Service report generation and Job code: DEMO_REPORT_JOB. Add a useful description.
3. In Published content choose Service operations report and its published version by name. The application fills its identity, version, revision and content hash.
4. Add Reason as a text Value: Reference-data setup: generate the approved service operations report. Use the offered contract inputs; do not invent reportId/version values.
5. Set Timeout to 300 seconds for the walkthrough if appropriate. Start with Maximum attempts 1 and overlap policy Wait in queue. Verify retry tuning separately.
6. Save draft. Select Preview on the saved job row. Inspect the operation, execution context, resolved values and pinned artifact.
7. Return to the row and Submit for review. Checker independently previews the same revision, then Approve or Return. Publish the approved job version.
Screen 1Job inputs bind a named published reportExisting application recorded test · example records may differ from your tenant · click to enlarge
• The selector supplies the version and content hash automatically.
• Execution policy is saved with the job definition.
Screen 2Job preview resolves inputs without executing the business operationExisting application recorded test · example records may differ from your tenant · click to enlarge
• Preview establishes current saved-definition eligibility.
• It does not generate the report; an actual run comes later.
Expected result
A published report job is available to Run a job, Schedules and compatible batch steps.
A job’s saved artifact reference is pinned. Publishing report version 2 does not make this job use version 2. Change the job through its supported new-version/review/publication flow and then update dependent schedules/batches explicitly.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","A published report job is available to Run a job, Schedules and compatible batch steps.",documentation/KERNEL_DOCUMENTATION_HUB.html#scheduler-demo/step-1-2,R1-G07; R1-G08; R1-G09,Not run,,,,,,,Not run,
SCHEDULER-01-03,R1-SCHEDULER-01,Enterprise Scheduler,"Define, publish and run a job",Module journey,P1,Job Definitions → New job for each artifact,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Job Definitions → New job for each artifact | 
Who acts | Scheduler Maker → Checker → Publisher | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Scheduler Maker → Checker → Publisher
Open: Job Definitions → New job for each artifact
Job | Business operation / content | Inputs to verify | 
DEMO_DASH_JOB | Run published Vista dashboard → Service operations dashboard | Reason; dashboard version/revision/hash supplied by the selector | 
DEMO_EMAIL_JOB | Generate published Pulse email → Service review email | Record key = CASE1001 when bound; sender and recipient; reason and any offered merge inputs | 
DEMO_LETTER_JOB | Generate published Pulse letter → Service review letter | Record key = CASE1001 when bound; reason and any offered merge inputs; no email sender/recipient | 
DEMO_REFRESH_JOB | Refresh published source connection → Demo service records API | Reason; connection version/revision/hash supplied by the selector | 
1. For each job, select the matching registered operation before choosing its published content. Email and letter choices are filtered by channel.
2. Use the same approved execution identity and domain for all jobs if they will form one batch. Verify this identity’s access to every dataset and report behind the artifacts.
3. For the email job use a controlled sender and recipient. Example-only addresses such as sender@example.test and recipient@example.test are suitable for explaining file composition; they are not deliverable mailboxes.
4. For both bound Pulse templates supply the exact parent Record key. The producer loads the saved dataset mapping and current authorized record at execution.
5. Save, Preview, Submit for review, obtain an independent current preview and decision, then Publish each job. Record its published version.
Screen 3Dashboard job selects a published dashboardExisting application recorded test · example records may differ from your tenant · click to enlarge
• Every pinned report tile is checked at execution.
• All tiles must be available for a successful scheduled dashboard result.
Screen 4Source-refresh job selects a published connectionExisting application recorded test · example records may differ from your tenant · click to enlarge
• Refresh uses the saved authentication reference and current execution permissions.
• Subsequent dataset reads consume the authorized snapshot.
Expected result
Four business-content jobs and the optional source-refresh job are published. Each points to the intended approved artifact version.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Four business-content jobs and the optional source-refresh job are published. Each points to the intended approved artifact version.,documentation/KERNEL_DOCUMENTATION_HUB.html#scheduler-demo/step-1-3,R1-G07; R1-G08; R1-G09,Not run,,,,,,,Not run,
SCHEDULER-01-04,R1-SCHEDULER-01,Enterprise Scheduler,"Define, publish and run a job",Module journey,P1,Job definition → Inputs,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Job definition → Inputs | 
Who acts | Scheduler Maker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Scheduler Maker
Open: Job definition → Inputs
1. Choose an input permitted by the selected operation’s schema. For example, bind the email job’s recipient to the authorized primary dataset’s recipient_email.
2. Set Input source to Dataset field. Select the published dataset, value field recipient_email, unique key field record_id and exact record CASE1001.
3. Add the input and inspect the resulting input grid. Keep Record key consistent with the Pulse template’s intended parent record.
4. Save and Preview. Confirm the currently resolved value and its dataset version/contract. Submit/review/publish the changed definition as required.
5. At execution the binding is read and validated again. Verify a changed value only using a controlled source update followed by the required snapshot refresh; then compare the actual output.
Expected result
The job reads a current authorized value for one explicitly selected record. Missing access, missing/ambiguous keys or incompatible values fail rather than silently using an unrelated record.
Dataset field binding is not “run once per every dataset row.” The inspected input model selects one record per binding. Do not claim bulk-recipient fan-out, arbitrary output-to-input piping or a generic ETL loop. Use a registered business operation for any additional bulk behavior.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The job reads a current authorized value for one explicitly selected record. Missing access, missing/ambiguous keys or incompatible values fail rather than silently using an unrelated record.",documentation/KERNEL_DOCUMENTATION_HUB.html#scheduler-demo/step-1-4,R1-G07; R1-G08; R1-G09,Not run,,,,,,,Not run,
SCHEDULER-01-05,R1-SCHEDULER-01,Enterprise Scheduler,"Define, publish and run a job",Module journey,P1,Scheduler → Job Runs → Run a job,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Scheduler → Job Runs → Run a job | 
Who acts | Authorized Scheduler operator | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Authorized Scheduler operator
Open: Scheduler → Job Runs → Run a job
1. Select the published Service report generation job. Preview current inputs, provide the execution reason and select Queue run. Record the run reference.
2. Refresh the run. Follow Queued → Claimed/Running → Waiting external where applicable → Succeeded or an explicit failure.
3. Open Details. Inspect the exact job version, attempt information, execution timestamps and Producer result reference.
4. Repeat for the dashboard, email and letter jobs, one at a time for the user walkthrough.
5. For each producer result, open the appropriate authorized Vista/Pulse output screen or access-controlled result view. Compare it with the manual output and intended case.
6. Record actual outcomes in LIVE_DEMO_CHECKLIST.csv. Do not mark a queued/accepted job as a successful generated output.
Job | Required success evidence | Extra check | 
Report | Scheduler SUCCEEDED + completed report result reference | Expected dataset scope, values and published report version | 
Dashboard | Scheduler SUCCEEDED + completed snapshot | Every tile available; PARTIAL is not success | 
Email | Scheduler SUCCEEDED + READY generated-email reference | Correct record, sender/recipient in file; no claim of send | 
Letter | Scheduler SUCCEEDED + READY letter/PDF reference | Correct recipient/reference and pagination | 
Scheduled work can run as a service identity different from the operator. Producer output lists are access-controlled and may be requester-scoped. A result absent from the operator’s personal Generated Emails/Rendered letters list is not proof that no output exists. Use the authorized result access path and the scheduler’s recorded producer reference; do not broaden permissions just to expose another identity’s output.
Expected result
All four actual executions have a result reference and a verified output. Rehearse these before enabling a recurring schedule.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",All four actual executions have a result reference and a verified output. Rehearse these before enabling a recurring schedule.,documentation/KERNEL_DOCUMENTATION_HUB.html#scheduler-demo/step-1-5,R1-G07; R1-G08; R1-G09,Not run,,,,,,,Not run,
SCHEDULER-01-06,R1-SCHEDULER-01,Enterprise Scheduler,"Define, publish and run a job",Module journey,P1,Scheduler → Job Runs → Details,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Scheduler → Job Runs → Details | 
Who acts | Authorized auditor/operator | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Authorized auditor/operator
Open: Scheduler → Job Runs → Details
1. Open a completed run and identify job version, requested/completed timestamps, status and producer result reference.
2. Review attempts and ordered audit events such as queued, claimed, dispatched, waiting external and succeeded/failed.
3. Select Download audit and retain the exported file unchanged.
4. Use the Audit file / Verify audit file control to select that file. The browser calculates its hash and verifies its receipt with the server; the full file remains in the browser.
5. If using tamper detection, use a separate edited copy of a demo audit export. Its verification should fail without altering the original server history.
6. Open the job/schedule/queue/backfill/batch Audit history where offered to connect the approval and operational actions to execution.
Screen 5Run details, producer reference and audit verificationExisting application recorded test · example records may differ from your tenant · click to enlarge
• A successful scheduler run must have its producer outcome explained.
• Choose an actual exported audit file; the screenshot has no file selected.
Expected result
The authorized user can trace who created/reviewed/published the definition, what version ran, what happened at each attempt and how the output reference is preserved.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The authorized user can trace who created/reviewed/published the definition, what version ran, what happened at each attempt and how the output reference is preserved.",documentation/KERNEL_DOCUMENTATION_HUB.html#scheduler-demo/step-1-6,R1-G07; R1-G08; R1-G09,Not run,,,,,,,Not run,
SCHEDULER-02-01,R1-SCHEDULER-02,Enterprise Scheduler,Create and operate a schedule,Module journey,P1,Scheduler → Business Calendars → New calendar,"Prepare published source connection, Vista report/dashboard and Pulse email/letter templates with reviewed datasets. Use compatible domain and execution identity for batch jobs. Verify the physical worker/queue is available. Use isolated fixtures for failure, pause or capacity demonstrations; do not stop a shared production worker to create a failure.","Before you act | Required context | 
Screen / entry | Scheduler → Business Calendars → New calendar | 
Who acts | Calendar Maker → Checker → Publisher | 
You need | Prepare published source connection, Vista report/dashboard and Pulse email/letter templates with reviewed datasets. Use compatible domain and execution identity for batch jobs. Verify the physical worker/queue is available. Use isolated fixtures for failure, pause or capacity demonstrations; do not stop a shared production worker to create a failure. | 
Steps and field guidance
Who: Calendar Maker → Checker → Publisher
Open: Scheduler → Business Calendars → New calendar
1. Enter a calendar name/code and choose the intended IANA timezone, for example America/New_York for a US business-day walkthrough.
2. Select the working days and local working windows, for example Monday–Friday 09:00–17:00. The end of a window is excluded.
3. Add a date exception: either closed for a holiday or explicit special working hours. Note that this replaces the usual working day.
4. Save draft and Preview the dates. Checker previews independently, approves/returns, and an authorized publisher publishes.
5. Select this published calendar in a new schedule. Review the upcoming occurrences in both the calendar’s local timezone and UTC.
6. For cron schedules choose a DST gap policy (skip or shift forward) and fold policy (first, second or both occurrences). Preview the relevant boundary dates before enabling.
Screen 6Business calendar authoringExisting application recorded test · example records may differ from your tenant · click to enlarge
• Working windows use local 24-hour times.
• Holidays and special hours are versioned and reviewed before publication.
Expected result
The schedule respects a specific published calendar version. Local-time expectations are checked against its actual preview.
Fixed elapsed intervals do not behave like “09:00 local every day” across daylight-saving changes. Editing/publishing a calendar does not automatically rebind existing schedules to a new calendar version.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The schedule respects a specific published calendar version. Local-time expectations are checked against its actual preview.,documentation/KERNEL_DOCUMENTATION_HUB.html#scheduler-demo/step-2-1,R1-G07; R1-G08; R1-G09,Not run,,,,,,,Not run,
SCHEDULER-02-02,R1-SCHEDULER-02,Enterprise Scheduler,Create and operate a schedule,Module journey,P1,Scheduler → Schedules → New schedule,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Scheduler → Schedules → New schedule | 
Who acts | Scheduler Maker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Scheduler Maker
Open: Scheduler → Schedules → New schedule
1. Select the published job version. Enter name/code, for example Service report weekday schedule / DEMO_REPORT_SCHEDULE.
2. For the first live execution choose Run once and a future execution time with enough time to complete review. Enter the UTC instant in the field explicitly labelled UTC.
3. Choose the display/calendar Time zone. Inspect both UTC and local time in Preview rather than relying on the browser’s timezone.
4. For repetition choose Fixed elapsed interval with a UTC anchor and interval seconds, or Calendar schedule with a five-field cron expression.
5. Optionally select a published Business calendar. It pins that calendar version and constrains the schedule to its allowed dates/windows.
6. Choose the missed-execution policy and limits. Save draft, Preview upcoming dates and current input bindings, then Submit for review.
7. Checker performs its own current Preview and Approve or Return. An authorized publisher uses Publish and enable when the approved revision has a fresh preview.
8. Open Job Runs after the occurrence. Verify the schedule’s run and producer result, then pause or retire the demo schedule after use.
Screen 7Schedule timing, calendar and missed-execution behaviorExisting application recorded test · example records may differ from your tenant · click to enlarge
• A schedule pins an exact published job version.
• Saving a draft does not enable execution.
Trigger | Example | Use | 
Run once | A chosen future UTC instant | One client-demo execution | 
Fixed elapsed interval | Anchor in UTC; every 3600 seconds | Elapsed hourly cadence independent of local DST | 
Calendar schedule | 0 9 * * 1-5 in the chosen timezone | 09:00 on weekdays | 
Calendar schedule | 0 9 * * 1 | Monday at 09:00 | 
Calendar schedule | 0 9 1 * * | First day of each month at 09:00 | 
Create separate schedules for the email, letter and dashboard jobs using the same procedure when they need independent timing. A schedule is a job trigger; the inspected schedule selector does not establish timer-triggered batch execution. Verify batch execution through Batches, as described later.
Check before continuing: The saved reviewed schedule references the intended published job version, timezone and calendar. Its upcoming occurrences and missed-execution behavior match the requested timing.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The saved reviewed schedule references the intended published job version, timezone and calendar. Its upcoming occurrences and missed-execution behavior match the requested timing.",documentation/KERNEL_DOCUMENTATION_HUB.html#scheduler-demo/step-2-2,R1-G07; R1-G08; R1-G09,Not run,,,,,,,Not run,
SCHEDULER-02-03,R1-SCHEDULER-02,Enterprise Scheduler,Create and operate a schedule,Module journey,P1,"Timeouts, retries, overlaps and misfires","Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Timeouts, retries, overlaps and misfires | 
Who acts | Authorized operator / reviewer | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Setting | Where | Meaning / user walkthrough | 
Timeout | Job Definition | Maximum operation time; a timeout is not evidence that a remote side effect never happened | 
Maximum attempts / retry delay | Job Definition | Bounded retries only when the registered operation supports the required stable retry key | 
Wait in queue | Job overlap policy | A later occurrence waits while the previous run is active | 
Skip overlapping work | Job overlap policy | Reject/skip overlapping execution according to the published job policy | 
Bounded concurrency | Job overlap policy | Permit a limited number of concurrent runs; queue-wide limits still apply | 
Skip expired occurrences | Schedule missed-execution policy | Do not replay expired occurrences | 
Fire once | Schedule missed-execution policy | Coalesce missed work into one occurrence according to the scheduler policy | 
Catch up | Schedule missed-execution policy | Admit bounded missed occurrences; configure per-batch limit and grace | 
The inspected job editor bounds timeout to 1–86400 seconds, attempts to 1–10 for eligible operations, and bounded concurrency to 1–32. Schedule catch-up batches are limited to 1–100 occurrences. Use sensible small demo values instead of treating these maxima as recommendations.
1. Show the published policy on one job and schedule. Explain its effect before changing it.
2. Use a prepared isolated failing operation/run to show an allowed retry and its retained attempt history. Do not deliberately stop a shared production worker.
3. Compare an automatic retry with a manual Rerun. A retry belongs to the existing run/attempt lifecycle; rerun creates a linked new execution.
4. If the state is Reconciliation required, inspect producer status and possible side effects before any permitted recovery.
Expected result
Failure handling is bounded, auditable and consistent with the registered producer contract. Scheduling does not make every operation safely repeatable.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","Failure handling is bounded, auditable and consistent with the registered producer contract. Scheduling does not make every operation safely repeatable.",documentation/KERNEL_DOCUMENTATION_HUB.html#scheduler-demo/step-2-3,R1-G07; R1-G08; R1-G09,Not run,,,,,,,Not run,
SCHEDULER-02-04,R1-SCHEDULER-02,Enterprise Scheduler,Create and operate a schedule,Module journey,P1,Scheduler → Queues & Workers,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Scheduler → Queues & Workers | 
Who acts | Queue Maker/Checker; authorized runtime operator | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Queue Maker/Checker; authorized runtime operator
Open: Scheduler → Queues & Workers
1. Inspect the existing queue policy for the current demo domain. Only use a dedicated demo queue for a live capacity-change walkthrough.
2. Create or edit a queue-policy draft with name/code, maximum concurrent runs and maximum pending requests.
3. Preview impact. Compare Current policy, Proposed policy and Current workload. Submit for review; the Checker previews independently and approves/returns; publish when authorized.
4. Verify Pause claims and Resume claims only on the isolated queue. Pausing claims does not cancel accepted work; pending capacity limits still apply.
5. Open Workers. Show worker state, last heartbeat, concurrency and active leases. The inspected UI describes 30-second reports and stale status after two minutes.
6. Explain Drain worker: accepted work continues while new claims stop. Resume when eligible. Retire a worker record only when its current lifecycle allows it.
7. Open Audit history for the relevant policy and worker actions.
Screen 8Checker reviews queue-policy impactExisting application recorded test · example records may differ from your tenant · click to enlarge
• Lower limits do not cancel already accepted work.
• Preview measures the current domain’s workload at preview time.
Expected result
The client sees the difference between a reviewed capacity policy, an operational pause and a physical running worker.
The UI manages policy and registered worker state; it does not install a new physical worker process. Do not drain or pause a shared production worker simply to create an on-screen failure for this example.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The client sees the difference between a reviewed capacity policy, an operational pause and a physical running worker.",documentation/KERNEL_DOCUMENTATION_HUB.html#scheduler-demo/step-2-4,R1-G07; R1-G08; R1-G09,Not run,,,,,,,Not run,
SCHEDULER-02-05,R1-SCHEDULER-02,Enterprise Scheduler,Create and operate a schedule,Module journey,P1,"Job Runs, Schedules and Job Definitions → eligible row actions","Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Job Runs, Schedules and Job Definitions → eligible row actions | 
Who acts | Authorized operator | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
1. Open the existing run, schedule or job and inspect its current status and last producer result.
2. Choose the single action that matches your need from the table below. Check the effect on already accepted work before confirming.
3. For a rerun, preview current inputs and supply the reason; for schedule resumption, inspect upcoming dates and missed-execution behavior.
4. Confirm the eligible action once. Refresh the originating record, retain the new receipt/reference and compare it with the original history.
Who: Authorized operator
Open: Job Runs, Schedules and Job Definitions → eligible row actions
Action | Procedure | Important effect | 
Rerun a completed/failed eligible run | Open run → Rerun → Preview current inputs → reason → Queue run | New linked run; same approved job version; current data may differ | 
Cancel queued run | Select Cancel queued run and confirm the reason | Only eligible queued work; not a rollback of accepted external work | 
Pause schedule | Open eligible schedule row → Pause → reason | Stops future scheduling; already accepted/queued runs remain separate | 
Resume schedule | Preview upcoming dates/current inputs, then Resume when eligible | Missed-execution policy governs the resumption | 
Retire schedule | Use its offered retirement action and reason | Retains historical occurrences/runs | 
Retire job | Use the job’s permitted retirement action | Stops new runs for the retired job; accepted work/history are retained | 
Create new job version | Branch/edit the supported draft → save → preview → review → publish | Dependents must explicitly select the new published version | 
Do not rerun uncertain external effects merely because the screen timed out. Reconciliation-required runs block automatic rerun. Changing a record to inactive or retired is not a universal cancellation or deletion mechanism.
Expected result
Every operator action has a reason and a retained audit trail. The original failed run is still visible after recovery.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Every operator action has a reason and a retained audit trail. The original failed run is still visible after recovery.,documentation/KERNEL_DOCUMENTATION_HUB.html#scheduler-demo/step-2-5,R1-G07; R1-G08; R1-G09,Not run,,,,,,,Not run,
SCHEDULER-03-01,R1-SCHEDULER-03,Enterprise Scheduler,Recover missed work and run dependent batches,Module journey,P1,Scheduler → Backfills,"Prepare published source connection, Vista report/dashboard and Pulse email/letter templates with reviewed datasets. Use compatible domain and execution identity for batch jobs. Verify the physical worker/queue is available. Use isolated fixtures for failure, pause or capacity demonstrations; do not stop a shared production worker to create a failure.","Before you act | Required context | 
Screen / entry | Scheduler → Backfills | 
Who acts | Backfill Maker → Checker → operator | 
You need | Prepare published source connection, Vista report/dashboard and Pulse email/letter templates with reviewed datasets. Use compatible domain and execution identity for batch jobs. Verify the physical worker/queue is available. Use isolated fixtures for failure, pause or capacity demonstrations; do not stop a shared production worker to create a failure. | 
Steps and field guidance
Who: Backfill Maker → Checker → operator
Open: Scheduler → Backfills
1. Choose a published schedule and a small prepared past time range with known missed occurrences. Range start/end use your browser timezone; the start is included and the end is excluded. Name the plan and explain the business reason.
2. Preview the plan. Inspect each occurrence, its timezone/UTC interpretation, planned action and any existing run status. Preview does not execute the job.
3. Confirm that existing runs are preserved and that only missing occurrences should be admitted. Check current input values and scope.
4. Submit for review. Checker previews the same plan independently and approves or returns.
5. Obtain a fresh approved-plan preview and select Enqueue. Follow the admitted runs and their producer results.
6. Use Pause/Resume only when eligible. Use Retire backfill to stop further admission when that lifecycle action is allowed. Existing accepted runs continue separately. Inspect progress and the audit history.
Screen 9Backfill preview preserves existing runsExisting application recorded test · example records may differ from your tenant · click to enlarge
• This historical example shows KEEP EXISTING for all listed occurrences; it would not create replacements for them.
• Use the actual UTC/local preview in your environment and resolve any discrepancy before enqueueing.
Expected result
Only missing occurrences are queued under the approved bounded plan; existing success, failure and cancellation history is preserved.
The inspected backfill is limited to a 31-day window and 100 planned occurrences. It uses current authorized input data, not a historical as-of reconstruction. A failed existing run is not “missing”; use its eligible rerun/recovery path.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","Only missing occurrences are queued under the approved bounded plan; existing success, failure and cancellation history is preserved.",documentation/KERNEL_DOCUMENTATION_HUB.html#scheduler-demo/step-3-1,R1-G07; R1-G08; R1-G09,Not run,,,,,,,Not run,
SCHEDULER-03-02,R1-SCHEDULER-03,Enterprise Scheduler,Recover missed work and run dependent batches,Module journey,P1,Scheduler → Batches → Batch definitions → New batch,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Scheduler → Batches → Batch definitions → New batch | 
Who acts | Batch Maker | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Batch Maker
Open: Scheduler → Batches → Batch definitions → New batch
1. Enter DEMO_SERVICE_BATCH / Service review pack. Choose a small concurrent-step limit and a reasonable run deadline.
2. Add the published source-refresh job as step Refresh source, with no prerequisite.
3. Add Generate report, Generate dashboard, Generate email and Generate letter steps using their published jobs. Set Refresh source as prerequisite for each. If you want a strictly sequential demo, make each step depend on the preceding step.
4. Use jobs in the same domain with the same approved execution identity. Inspect every version and remove cycles or missing prerequisites.
5. Save draft. Preview the dependency plan and current bindings. Submit for review; Checker performs its own preview and approves/returns; publish the approved batch.
6. Use the published batch’s run/start action with a reason. Open Batch runs → View steps and follow each job run reference and completion checkpoint.
7. Note that ordering the dashboard after a report job does not make the dashboard consume that prior run’s output automatically; dashboard execution invokes its own pinned report definitions.
Screen 10Batch steps and prerequisitesExisting application recorded test · example records may differ from your tenant · click to enlarge
• A step waits for all selected prerequisites to succeed.
• All selected published jobs must have compatible scope and execution identity.
Expected result
The source refresh completes before the dependent content jobs are admitted. A failure prevents dependent steps from being treated as successful.
Batch dependencies enforce execution order. They do not themselves implement attachment transfer, arbitrary step-output-to-input mapping, record-by-record fan-out or cross-system transaction rollback. If a later step needs those semantics, use a registered operation designed for them.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The source refresh completes before the dependent content jobs are admitted. A failure prevents dependent steps from being treated as successful.,documentation/KERNEL_DOCUMENTATION_HUB.html#scheduler-demo/step-3-2,R1-G07; R1-G08; R1-G09,Not run,,,,,,,Not run,
SCHEDULER-03-03,R1-SCHEDULER-03,Enterprise Scheduler,Recover missed work and run dependent batches,Module journey,P1,Batches → Batch runs → selected run,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Batches → Batch runs → selected run | 
Who acts | Authorized batch operator | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Who: Authorized batch operator
Open: Batches → Batch runs → selected run
1. Open View steps and show the job run reference, attempt generation, status and completion checkpoint for each step.
2. On a prepared isolated run, choose Pause when eligible. Accepted jobs can finish; future admission is paused.
3. Before Resume, use the run’s Preview and inspect unresolved failures or external effects. Resume only when the server presents it as eligible.
4. Show that succeeded-step checkpoints are retained and are not blindly repeated. A failed step can be retried only within the job’s permitted recovery policy.
5. Verify Stop admission with a reason on an isolated run if required. Note that this does not reverse already completed business operations.
6. Refresh progress and compare the retained failure/recovery history with final step results.
Screen 11Completed Vista, letter and email steps with checkpointsExisting application recorded test · example records may differ from your tenant · click to enlarge
• This is an earlier isolated execution recorded test, not a new Azure run for this guide.
• The checkpoint represents a completed job; the producer owns its internal progress.
Expected result
Recovery preserves successful work and makes unfinished or uncertain work explicit. The final batch outcome is supported by each child job result.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Recovery preserves successful work and makes unfinished or uncertain work explicit. The final batch outcome is supported by each child job result.,documentation/KERNEL_DOCUMENTATION_HUB.html#scheduler-demo/step-3-3,R1-G07; R1-G08; R1-G09,Not run,,,,,,,Not run,
SCHEDULER-03-04,R1-SCHEDULER-03,Enterprise Scheduler,Recover missed work and run dependent batches,Module journey,P1,"Update, deactivate and retain historical records","Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Update, deactivate and retain historical records | 
Who acts | Authorized operator / reviewer | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
1. Create a new version of a report/template when business content changes. Save, preview, independently review and publish that version.
2. If a dashboard should use the new report visual, update the dashboard definition through its versioned flow; otherwise it retains its old pinned report version.
3. Create and publish new job versions selecting the new content. Explicitly update/recreate schedules and batch definitions through their supported lifecycle to select the intended versions.
4. Use Deactivate/Reactivate only on records that expose those actions, such as source connections. Use the module’s Suspend/Resume/Retire actions where that is the defined lifecycle.
5. Inspect the impact on consumers before disabling a shared source. Current access/availability checks may block later preview or execution.
6. Preserve definitions, approvals, prior versions, outputs and run audit. Pause/retire walkthrough schedules and remove further admissions after the presentation.
Availability, publication, suspension and retirement are different concepts. An is_active flag is not a substitute for approval state or an instruction to erase past history. Use the screen’s offered, permission-controlled lifecycle action.
Expected result
The demo leaves no recurring job unintentionally enabled and demonstrates explicit version adoption instead of silent changes to approved automation.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The demo leaves no recurring job unintentionally enabled and demonstrates explicit version adoption instead of silent changes to approved automation.,documentation/KERNEL_DOCUMENTATION_HUB.html#scheduler-demo/step-3-4,R1-G07; R1-G08; R1-G09,Not run,,,,,,,Not run,
SCHEDULER-EX-01,R1-SCHEDULER-04,Enterprise Scheduler,Exception / recovery,Exception / recovery,P1,Run remains queued,"Prepare published source connection, Vista report/dashboard and Pulse email/letter templates with reviewed datasets. Use compatible domain and execution identity for batch jobs. Verify the physical worker/queue is available. Use isolated fixtures for failure, pause or capacity demonstrations; do not stop a shared production worker to create a failure.","1. Prepare a disposable record exhibiting this condition: Run remains queued.
2. Check worker heartbeat, paused claims, capacity and overlap policy.
3. Reopen the affected record and its history; verify: Do not create repeated Run now requests.
4. Record actual outcome and supporting record/version or denial evidence.",Do not create repeated Run now requests.,documentation/KERNEL_DOCUMENTATION_HUB.html#scheduler-manual/decision-guide,R1-G07; R1-G08; R1-G09,Not run,,,,,,,Not run,
SCHEDULER-EX-02,R1-SCHEDULER-04,Enterprise Scheduler,Exception / recovery,Exception / recovery,P1,Waiting external,"Prepare published source connection, Vista report/dashboard and Pulse email/letter templates with reviewed datasets. Use compatible domain and execution identity for batch jobs. Verify the physical worker/queue is available. Use isolated fixtures for failure, pause or capacity demonstrations; do not stop a shared production worker to create a failure.","1. Prepare a disposable record exhibiting this condition: Waiting external.
2. Inspect producer result and native polling/reconciliation.
3. Reopen the affected record and its history; verify: Acceptance is not terminal success.
4. Record actual outcome and supporting record/version or denial evidence.",Acceptance is not terminal success.,documentation/KERNEL_DOCUMENTATION_HUB.html#scheduler-manual/decision-guide,R1-G07; R1-G08; R1-G09,Not run,,,,,,,Not run,
SCHEDULER-EX-03,R1-SCHEDULER-04,Enterprise Scheduler,Exception / recovery,Exception / recovery,P1,Timeout with uncertain side effect,"Prepare published source connection, Vista report/dashboard and Pulse email/letter templates with reviewed datasets. Use compatible domain and execution identity for batch jobs. Verify the physical worker/queue is available. Use isolated fixtures for failure, pause or capacity demonstrations; do not stop a shared production worker to create a failure.","1. Prepare a disposable record exhibiting this condition: Timeout with uncertain side effect.
2. Reconcile producer/provider outcome first.
3. Reopen the affected record and its history; verify: Do not automatically resend or recreate external work.
4. Record actual outcome and supporting record/version or denial evidence.",Do not automatically resend or recreate external work.,documentation/KERNEL_DOCUMENTATION_HUB.html#scheduler-manual/decision-guide,R1-G07; R1-G08; R1-G09,Not run,,,,,,,Not run,
SCHEDULER-EX-04,R1-SCHEDULER-04,Enterprise Scheduler,Exception / recovery,Exception / recovery,P1,Need yesterday’s missed occurrence,"Prepare published source connection, Vista report/dashboard and Pulse email/letter templates with reviewed datasets. Use compatible domain and execution identity for batch jobs. Verify the physical worker/queue is available. Use isolated fixtures for failure, pause or capacity demonstrations; do not stop a shared production worker to create a failure.","1. Prepare a disposable record exhibiting this condition: Need yesterday’s missed occurrence.
2. Preview missing-only backfill and current data implications.
3. Reopen the affected record and its history; verify: An existing failed run needs eligible recovery, not replacement through backfill.
4. Record actual outcome and supporting record/version or denial evidence.","An existing failed run needs eligible recovery, not replacement through backfill.",documentation/KERNEL_DOCUMENTATION_HUB.html#scheduler-manual/decision-guide,R1-G07; R1-G08; R1-G09,Not run,,,,,,,Not run,
SCHEDULER-EX-05,R1-SCHEDULER-04,Enterprise Scheduler,Exception / recovery,Exception / recovery,P1,Need new report/template version,"Prepare published source connection, Vista report/dashboard and Pulse email/letter templates with reviewed datasets. Use compatible domain and execution identity for batch jobs. Verify the physical worker/queue is available. Use isolated fixtures for failure, pause or capacity demonstrations; do not stop a shared production worker to create a failure.","1. Prepare a disposable record exhibiting this condition: Need new report/template version.
2. Publish a new job version and explicitly update dependent schedules/batches.
3. Reopen the affected record and its history; verify: Version pins protect approved execution from silent change.
4. Record actual outcome and supporting record/version or denial evidence.",Version pins protect approved execution from silent change.,documentation/KERNEL_DOCUMENTATION_HUB.html#scheduler-manual/decision-guide,R1-G07; R1-G08; R1-G09,Not run,,,,,,,Not run,
SCHEDULER-EX-06,R1-SCHEDULER-04,Enterprise Scheduler,Exception / recovery,Exception / recovery,P1,Need to pass report bytes into email,"Prepare published source connection, Vista report/dashboard and Pulse email/letter templates with reviewed datasets. Use compatible domain and execution identity for batch jobs. Verify the physical worker/queue is available. Use isolated fixtures for failure, pause or capacity demonstrations; do not stop a shared production worker to create a failure.","1. Prepare a disposable record exhibiting this condition: Need to pass report bytes into email.
2. Use a registered operation with that supported contract.
3. Reopen the affected record and its history; verify: A batch arrow alone does not transfer attachments.
4. Record actual outcome and supporting record/version or denial evidence.",A batch arrow alone does not transfer attachments.,documentation/KERNEL_DOCUMENTATION_HUB.html#scheduler-manual/decision-guide,R1-G07; R1-G08; R1-G09,Not run,,,,,,,Not run,
CUSTODIA-01-01,R1-CUSTODIA-01,Custodia,Configure document capture,Module journey,P0,Create and approve a document class / content type,"Prepare a synthetic document with no personal information, an eligible content class/metadata configuration and authorized capture/reviewer identities. Confirm current processing services before promising a preview or download. Use a recipient you control for sharing demonstrations and a prepared non-destructive record for retention/hold explanations.","Before you act | Required context | 
Screen / entry | Create and approve a document class / content type | 
Who acts | Authorized operator / reviewer | 
You need | Prepare a synthetic document with no personal information, an eligible content class/metadata configuration and authorized capture/reviewer identities. Confirm current processing services before promising a preview or download. Use a recipient you control for sharing demonstrations and a prepared non-destructive record for retention/hold explanations. | 
Steps and field guidance
A document class establishes eligible file formats and the size policy for capture. Use Administration → Document classes / Content Types, or search Create document class. Have the class steward and an independent class reviewer available.
1. Search existing classes first. Create a unique code and a business-readable name.
2. Choose permitted file formats and maximum file size. A class may be stricter than the shared upload ceiling.
3. Save and open the created type’s setup. Inspect its metadata configuration and capture defaults.
4. Submit the class for its required review. Follow the created task rather than creating a second class.
5. The eligible reviewer opens Class review tasks, checks the submitted definition and records the offered decision and reason.
6. Refresh the class and confirm that the approved version appears in the capture lookup. A saved draft is not an approved capture choice.
Expected result
An approved class is eligible for intake; metadata and optional capture configuration can be attached in their governed flows.
Automatic content-type-wide retention, access and storage policy assignment is not established by this setup. The implemented governance operations act on the selected document.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",An approved class is eligible for intake; metadata and optional capture configuration can be attached in their governed flows.,documentation/KERNEL_DOCUMENTATION_HUB.html#custodia-demo/step-1-1,,Not run,,,,,,,Not run,
CUSTODIA-01-02,R1-CUSTODIA-01,Custodia,Configure document capture,Module journey,P0,Define a metadata schema and typed fields,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Define a metadata schema and typed fields | 
Who acts | Authorized operator / reviewer | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Use the selected content type’s contextual metadata setup or Metadata schemas. The schema defines what users must capture; document values are entered later.
1. Choose the approved document class. Enter Schema Code and Schema Name and select an eligible Independent Reviewer.
2. Use Add Metadata Field to define the required field keys, labels, types and constraints. Use typed fields rather than free-form JSON.
3. Define required values and permitted choices. For a controlled choice, prepare the approved vocabulary before referencing it.
4. Review the complete field list and enter a Change Reason. Save/submit through the available action.
5. The separate reviewer inspects Metadata reviews and decides the exact proposal.
6. For a later change, create a successor from the existing schema and review it. If scheduled effectiveness is used, inspect the effective date and current version.
7. Verify the capture form uses the currently effective approved schema. A successor does not rewrite existing document history.
Expected result
Capture presents typed and validated business fields under the selected approved configuration.
The displayed schema designer allows up to 40 typed fields. Required fields, supported types and limits are authoritative in the current form. An empty reviewer lookup means an eligible independent reviewer is still needed.Screen 1Contextual metadata schema form for the selected content type.Historical application recorded test · illustrative records · business-flow-migration/CUSTODIA_TYPE_FORM.png · click to enlarge. Appearance may differ in the installed release.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Capture presents typed and validated business fields under the selected approved configuration.,documentation/KERNEL_DOCUMENTATION_HUB.html#custodia-demo/step-1-2,,Not run,,,,,,,Not run,
CUSTODIA-01-03,R1-CUSTODIA-01,Custodia,Configure document capture,Module journey,P0,Controlled vocabularies and inspect an existing definition or use its request action.,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Controlled vocabularies and inspect an existing definition or use its request action. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Vocabularies provide approved choices for metadata. Classifications express document sensitivity and access requirements. They are related configuration tasks with different effects.
1. Open Controlled vocabularies and inspect an existing definition or use its request action.
2. Enter the code, label and proposed values required by the form, choose the reviewer and explain the change.
3. Complete Vocabulary reviews before using the new choices. Use successor/retirement actions for an existing approved definition.
4. Open Classifications to prepare a classification definition. Inspect its sensitivity and applicable controls with the records/security owner.
5. Complete Classification reviews. Assign the eligible classification from a document’s Security/contextual action.
6. Inspect Document classifications and the document’s activity to confirm the actual assignment. Definition approval alone does not classify every document.
Expected result
Users select controlled approved values and current document classifications participate in access checks.
Retirement keeps the governed history. It is not an instruction to delete prior values or original documents. A role’s screen access does not override classification clearance.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Users select controlled approved values and current document classifications participate in access checks.,documentation/KERNEL_DOCUMENTATION_HUB.html#custodia-demo/step-1-3,,Not run,,,,,,,Not run,
CUSTODIA-01-04,R1-CUSTODIA-01,Custodia,Configure document capture,Module journey,P0,Entry templates and request a new definition.,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Entry templates and request a new definition. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
An entry template is a reusable capture configuration for a supplied file. Pulse owns reusable letter/email content templates; the two template types have different purposes.
1. Open Entry templates and request a new definition.
2. Select an approved class and metadata schema, the optional approved classification, suggested title and typed metadata defaults.
3. Select the independent reviewer and submit the proposal. Inspect Entry template reviews for the decision.
4. After approval, use Capture with entry template. Choose the approved template and inspect the prefilled fields.
5. Select the file and complete or override only fields the form permits. Check the actual values before uploading.
6. Confirm the storage receipt, template provenance and subsequent security admission.
7. Use a reviewed successor to change future capture defaults. Earlier documents keep their own captured version and history.
Expected result
New capture uses the approved version and records its configuration provenance.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",New capture uses the approved version and records its configuration provenance.,documentation/KERNEL_DOCUMENTATION_HUB.html#custodia-demo/step-1-4,,Not run,,,,,,,Not run,
CUSTODIA-02-01,R1-CUSTODIA-02,Custodia,Capture and work with a document,Module journey,P0,the stored document from the result or library,"Prepare a synthetic document with no personal information, an eligible content class/metadata configuration and authorized capture/reviewer identities. Confirm current processing services before promising a preview or download. Use a recipient you control for sharing demonstrations and a prepared non-destructive record for retention/hold explanations.","Before you act | Required context | 
Screen / entry | the stored document from the result or library | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Prepare a synthetic document with no personal information, an eligible content class/metadata configuration and authorized capture/reviewer identities. Confirm current processing services before promising a preview or download. Use a recipient you control for sharing demonstrations and a prepared non-destructive record for retention/hold explanations. | 
Steps and field guidance
Prepare files that are permitted by the class. Use Upload document or the shared upload dialog. The recorded shared bounds are 20 files, 100 MiB total and 25 MiB per file, with stricter class limits still applied.
1. Select files. Remove an unintended selection before proceeding and read any format/size rejection.
2. Enter details. Choose the approved class or template and complete title and required metadata for each file.
3. Review. Verify each file, class, title and business values; fix validation errors before submission.
4. Upload. Keep the page open while the bounded batch runs and read each file’s outcome.
5. For partial success, retain completed receipts and retry only eligible failed entries using the offered action.
6. Open the stored document from the result or library. Continue its Processing stages.
7. Before leaving, inspect the leave warning. Stored documents remain; unfinished file selections and in-browser retry context may not.
Expected result
Each successful file has a storage receipt and document/version identity. Stored in quarantine is not yet admitted.
Supported format families in the recorded implementation include PDF, PNG/JPEG, text, Word DOC/DOCX, TIFF and ZIP, subject to class and worker support. ZIP extraction is bounded text processing; it does not automatically import each archive member as a separate document.Screen 2Review selected files and capture details before upload.Historical application recorded test · illustrative records · business-flow-migration/CUSTODIA_UPLOAD_REVIEW.png · click to enlarge. Appearance may differ in the installed release.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Each successful file has a storage receipt and document/version identity. Stored in quarantine is not yet admitted.,documentation/KERNEL_DOCUMENTATION_HUB.html#custodia-demo/step-2-1,,Not run,,,,,,,Not run,
CUSTODIA-02-02,R1-CUSTODIA-02,Custodia,Capture and work with a document,Module journey,P0,the selected document’s processing detail and confirm its document ID and exact version.,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | the selected document’s processing detail and confirm its document ID and exact version. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
1. Open the selected document’s processing detail and confirm its document ID and exact version.
2. Inspect each stage below in order. Open a blocked or failed stage to read its reason and available owner action.
3. Resolve eligible metadata or classification problems, or route admission/scanning failures to the responsible operator. Do not use quarantined bytes as ordinary content.
4. Refresh after the action and recheck the current version. Continue to business review or document use only when its required admission and policy conditions are satisfied.
Select a document from intake, exceptions or quarantine. Processing remains attached to that document and version. Refresh stages after a completed operation; if the version changed, reload before continuing.
Item | How to use it | 
1 · Receive | Confirm encrypted storage receipt and source identity. A failed transfer needs upload recovery. | 
2 · Security screening | Inspect scanner/admission outcome. Quarantined or blocked bytes are not ordinary viewable content. | 
3 · Content extraction | Inspect extraction/OCR outcome and supported format. Extraction success is separate from business correctness. | 
4 · Content type & classification | Confirm the approved type and current classification assignments. | 
5 · Metadata | Enter the required business values against the effective schema. | 
6 · Metadata validation | Resolve missing or invalid values shown for this document. | 
7 · Policy review | Complete required governance or independent checks. A missing configuration is not an approval. | 
8 · Indexing | Confirm the current source/version is searchable. Stale or missing indexes require supported recovery. | 
9 · Custody | Inspect readiness for permitted viewing, search and relationships. | 
Expected result
The stage rail and each stage’s detail explain completed, blocked, pending or unconfigured work. The fraction completed alone is not proof that every policy exists.Screen 3Document processing rail and custody detail for the selected version.Historical application recorded test · illustrative records · business-flow-migration/CUSTODIA_PROCESSING.png · click to enlarge. Appearance may differ in the installed release.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The stage rail and each stage’s detail explain completed, blocked, pending or unconfigured work. The fraction completed alone is not proof that every policy exists.",documentation/KERNEL_DOCUMENTATION_HUB.html#custodia-demo/step-2-2,,Not run,,,,,,,Not run,
CUSTODIA-02-03,R1-CUSTODIA-02,Custodia,Capture and work with a document,Module journey,P0,Enter document metadata and resolve validation,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Enter document metadata and resolve validation | 
Who acts | Authorized operator / reviewer | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Open the selected document’s Metadata tab or the metadata processing stage. Configuration authoring and entering document values are separate activities.
1. Check the document title, version, class and effective schema.
2. Complete required fields using their appropriate text, number, date, time, boolean or controlled-choice controls.
3. Use multi-value controls only when the schema permits multiple values. Do not place several unrelated values in a single typed field.
4. Save the current values and read validation messages. Correct the named field rather than changing the class to bypass a rule.
5. Complete any required metadata review through its offered task.
6. Refresh the processing stages and inspect metadata/activity history to confirm the result.
Expected result
Current values satisfy the applicable schema and remain associated with the correct document version.
An unauthorized metadata field can be hidden or read-only. Full-text search and facets also apply current field permissions; missing values in search can be an access outcome.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Current values satisfy the applicable schema and remain associated with the correct document version.,documentation/KERNEL_DOCUMENTATION_HUB.html#custodia-demo/step-2-3,,Not run,,,,,,,Not run,
CUSTODIA-02-04,R1-CUSTODIA-02,Custodia,Capture and work with a document,Module journey,P0,"Versions and inspect the current version, earlier versions, source checksum and checkout state.","Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Versions and inspect the current version, earlier versions, source checksum and checkout state. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Versions preserve immutable content. A title change is not a content replacement. Use a non-sensitive training document to verify versioning.
1. Open Versions and inspect the current version, earlier versions, source checksum and checkout state.
2. Use Checkout when editing is authorized. An existing exclusive checkout can block another editor.
3. Use Check-in with the intended replacement file and the required context. Keep the confirmed receipt and new version reference.
4. Wait for the replacement’s own admission and processing checks before relying on it.
5. To abandon an unused checkout, use Cancel checkout. It does not delete earlier content.
6. Use Rename for a permitted business-title correction and refresh the document after the command.
7. Use Verify version / permitted historical retrieval when needed to inspect exact content identity and integrity.
Expected result
A new version retains the previous version history; changed titles do not manufacture a new content approval.
If the record changed since you opened it, refresh and inspect the latest revision. Grants, redactions, review tasks and exports can be pinned to a particular version; do not assume they move automatically to a replacement.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",A new version retains the previous version history; changed titles do not manufacture a new content approval.,documentation/KERNEL_DOCUMENTATION_HUB.html#custodia-demo/step-2-4,,Not run,,,,,,,Not run,
CUSTODIA-02-05,R1-CUSTODIA-02,Custodia,Capture and work with a document,Module journey,P0,"Preview, print and download a document","Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Preview, print and download a document | 
Who acts | Authorized operator / reviewer | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Preview, page printing and original download are separately authorized. Open Preview for the exact eligible version, or open a currently valid shared grant.
1. Confirm admission and the requested version before opening the viewer.
2. Navigate pages and use zoom to inspect the content. Reflowed text layouts are labelled; PDF page rendering preserves its source page layout.
3. Use the viewer’s current-page print only when offered. The browser print dialog does not prove a physical print completed.
4. Use original download only when separately authorized. The original preserves its original bytes.
5. Close the viewer when finished. On session expiry, reopen through the document’s authorized viewer action rather than reusing an old page URL.
Expected result
The permitted representation is displayed with current version, classification, grant and redaction checks.
Approved redaction masks protect rendered pages. They do not rewrite the original file. Viewer runtime limits can be stricter than upload limits; a file accepted for storage is not guaranteed to support every preview representation.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The permitted representation is displayed with current version, classification, grant and redaction checks.",documentation/KERNEL_DOCUMENTATION_HUB.html#custodia-demo/step-2-5,,Not run,,,,,,,Not run,
CUSTODIA-02-06,R1-CUSTODIA-02,Custodia,Capture and work with a document,Module journey,P0,the exact document version in the authorized page viewer.,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | the exact document version in the authorized page viewer. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Use notes to record private observations. Use redaction requests for exact page regions that need independent approval. These actions have different visibility and consequences.
1. Open the exact document version in the authorized page viewer.
2. Add a private note where offered. Keep its purpose clear; a private annotation is not an organization-wide business decision.
3. For redaction, identify the page and rectangle, enter the required reason and submit the request.
4. An eligible separate reviewer opens Redaction reviews, inspects the proposed region and exact version, and records the decision.
5. Reopen the permitted rendered page after approval and verify the burned-in mask.
6. For removal or correction, use the governed removal/review action. A changed mask can invalidate an earlier redacted export.
Expected result
The approved mask is bound to the reviewed version; original bytes and private-note handling remain separate.
Do not send an original download expecting the rendered mask to have changed it. Search snippets/raw text can be suppressed for masked versions to avoid disclosing covered content.Screen 4Page annotations and exact-version redaction controls.Historical application recorded test · illustrative records · annotations/annotations-desktop.png · click to enlarge. Appearance may differ in the installed release.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The approved mask is bound to the reviewed version; original bytes and private-note handling remain separate.,documentation/KERNEL_DOCUMENTATION_HUB.html#custodia-demo/step-2-6,,Not run,,,,,,,Not run,
CUSTODIA-02-07,R1-CUSTODIA-02,Custodia,Capture and work with a document,Module journey,P0,a result and confirm its version and context before using its content.,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | a result and confirm its version and context before using its content. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Use the library for document records and Content search for supported extracted text, facets and metadata filters. The current source/version must be admitted, accessible and indexed where required.
1. Enter a meaningful search term and apply the relevant class, file type and metadata filters.
2. Inspect result count, facets and paging. Counts are calculated after access checks.
3. Open a result and confirm its version and context before using its content.
4. If no result is found, clear filters and check current admission/index status; ask the owner to investigate only after confirming scope.
5. Save the search definition if offered. Give it a recognizable name and reuse it from your saved definitions.
6. Rerun a saved search to obtain current authorized results. It stores criteria, not a frozen copy of all documents.
Expected result
Search returns permitted current results and does not expose denied metadata through facets or counts.Screen 5Content search following document processing.Historical application recorded test · illustrative records · business-flow-migration/CUSTODIA_SEARCH.png · click to enlarge. Appearance may differ in the installed release.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Search returns permitted current results and does not expose denied metadata through facets or counts.,documentation/KERNEL_DOCUMENTATION_HUB.html#custodia-demo/step-2-7,,Not run,,,,,,,Not run,
CUSTODIA-02-08,R1-CUSTODIA-02,Custodia,Capture and work with a document,Module journey,P0,"Collections, inspect or create an authorized collection and choose its permitted parent when applicable.","Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Collections, inspect or create an authorized collection and choose its permitted parent when applicable. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Collections organize documents. Relationships connect a document to another document or a public business reference. Neither grants content access.
1. Open Collections, inspect or create an authorized collection and choose its permitted parent when applicable.
2. Use Collection membership to add eligible documents. Inspect membership before removing an unintended association.
3. Use System collections for computed views such as admitted, awaiting admission or your checked-out documents. These views do not accept manual membership edits.
4. Open the document’s Relationships tab to create a permitted typed link.
5. For a document target, select the eligible target and inspect its version/provenance. For an external reference, supply the owning application, object type and public reference required by the form.
6. Verify the saved relationship and its history. Retire a wrong link through the offered action rather than altering the target document.
Expected result
Organization and provenance links remain visible while each underlying document retains its own permissions.
External reference capture does not certify that a remote record exists. Relationship-type authoring, broader cross-owner collection policy and configurable system-collection lifecycle remain outside the confirmed flow. System-collection previews are bounded; use the library for broader search.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Organization and provenance links remain visible while each underlying document retains its own permissions.,documentation/KERNEL_DOCUMENTATION_HUB.html#custodia-demo/step-2-8,,Not run,,,,,,,Not run,
CUSTODIA-03-01,R1-CUSTODIA-03,Custodia,Share and independently review documents,Module journey,P0,Request and review controlled sharing,"Prepare a synthetic document with no personal information, an eligible content class/metadata configuration and authorized capture/reviewer identities. Confirm current processing services before promising a preview or download. Use a recipient you control for sharing demonstrations and a prepared non-destructive record for retention/hold explanations.","Before you act | Required context | 
Screen / entry | Request and review controlled sharing | 
Who acts | Authorized operator / reviewer | 
You need | Prepare a synthetic document with no personal information, an eligible content class/metadata configuration and authorized capture/reviewer identities. Confirm current processing services before promising a preview or download. Use a recipient you control for sharing demonstrations and a prepared non-destructive record for retention/hold explanations. | 
Steps and field guidance
Sharing creates internal recipient grants for selected admitted versions. It does not send an outbound email/fax or grant every recipient all document actions.
1. Select the document/version and open Request shared access, or select eligible library rows and choose Share documents.
2. Choose the recipient and an eligible independent reviewer. Owner, recipient and reviewer independence rules still apply.
3. Enter the retrieval purpose, expiry with timezone or the displayed local-time control, allowed actions and any usage limit.
4. For a batch, inspect every document/recipient pair. The recorded bounds are 20 documents, 10 recipients and at most 50 approval pairs.
5. Submit for review. Record the per-pair results and retry only failed eligible pairs; successful requests must not be duplicated.
6. The reviewer opens Access grant reviews, inspects version, purpose, recipient, actions and expiry and records the offered decision.
7. After approval, confirm the grant in Shared access and have the recipient inspect Shared with me.
8. When the purpose ends, use Revoke shared access or allow the grant to expire. Retain its history.
Expected result
Only approved, current grants expose the permitted version and actions to the intended recipient.Screen 6Bounded sharing: selected documents, recipients, purpose, expiry and requested actions.Historical application recorded test · illustrative records · delivery-actions/BATCH_SHARING.png · click to enlarge. Appearance may differ in the installed release.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","Only approved, current grants expose the permitted version and actions to the intended recipient.",documentation/KERNEL_DOCUMENTATION_HUB.html#custodia-demo/step-3-1,,Not run,,,,,,,Not run,
CUSTODIA-03-02,R1-CUSTODIA-03,Custodia,Share and independently review documents,Module journey,P0,Shared with me / Shared documents and locate the grant by its document and purpose.,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Shared with me / Shared documents and locate the grant by its document and purpose. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
The recipient must have both an eligible grant and the necessary current IAM action access. Changing profile or an expired grant can change what appears.
1. Sign in as the actual recipient and select the intended domain/profile.
2. Open Shared with me / Shared documents and locate the grant by its document and purpose.
3. Check the exact version, expiry and permitted actions before opening it.
4. Use only the offered view, print or original download action. A view-only grant should not provide original download.
5. If the item disappears or becomes unavailable, ask the owner to check revocation, expiry, usage limits, current classification and recipient identity.
6. For a different version or extended purpose, request a new governed grant rather than passing an old viewer URL to another person.
Expected result
Recipient access follows current authority and preserves the scope originally reviewed.Screen 7Shared document workspace for the current recipient.Historical application recorded test · illustrative records · delivery-completion/SHARED_DOCUMENTS.png · click to enlarge. Appearance may differ in the installed release.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Recipient access follows current authority and preserves the scope originally reviewed.,documentation/KERNEL_DOCUMENTATION_HUB.html#custodia-demo/step-3-2,,Not run,,,,,,,Not run,
CUSTODIA-03-03,R1-CUSTODIA-03,Custodia,Share and independently review documents,Module journey,P0,the exact task,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | the exact task | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Review queues group pending governance work. The current record and task determine whether you may decide. Seeing the review page does not make every task eligible.
1. Select the reviewer profile and open the relevant review queue or the originating record’s review action.
2. Open the exact task. Read requester, object/version, proposed change, reason, scope and current workflow stage.
3. Inspect the supporting document or configuration through the authorized context. A task assignment does not automatically grant unrestricted document content.
4. Use only the decision options offered for that family. Enter a clear reason, especially when returning or rejecting.
5. Submit once and wait for a confirmed result. If the result is uncertain, use the offered recovery or refresh the same task.
6. Return to the originating record and confirm its state/effective values. Approval may enable a separate execution action rather than execute it.
7. If the source changed, refresh and obtain a new exact review as required. Do not reuse an earlier decision for changed scope.
Expected result
The decision is attributable to an eligible independent actor and the reviewed version.
New review instances use the configured native Regulix definitions; existing instances can remain pinned to their original workflow. Reassignment/deadline changes require their own permitted routing action.Screen 8Review queue with current tasks and their available decisions.Historical application recorded test · illustrative records · delivery-completion/REVIEW_QUEUE.png · click to enlarge. Appearance may differ in the installed release.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The decision is attributable to an eligible independent actor and the reviewed version.,documentation/KERNEL_DOCUMENTATION_HUB.html#custodia-demo/step-3-3,,Not run,,,,,,,Not run,
CUSTODIA-04-01,R1-CUSTODIA-04,Custodia,Manage retention and preservation,Module journey,P0,Retention schedules and inspect or request the appropriate duration/trigger policy.,"Prepare a synthetic document with no personal information, an eligible content class/metadata configuration and authorized capture/reviewer identities. Confirm current processing services before promising a preview or download. Use a recipient you control for sharing demonstrations and a prepared non-destructive record for retention/hold explanations.","Before you act | Required context | 
Screen / entry | Retention schedules and inspect or request the appropriate duration/trigger policy. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Prepare a synthetic document with no personal information, an eligible content class/metadata configuration and authorized capture/reviewer identities. Confirm current processing services before promising a preview or download. Use a recipient you control for sharing demonstrations and a prepared non-destructive record for retention/hold explanations. | 
Steps and field guidance
Retention governs how long a document must be preserved. The approved schedule, document assignment, triggering event and legal holds have separate records.
1. Open Retention schedules and inspect or request the appropriate duration/trigger policy.
2. Choose the required independent reviewer and complete the request/review process.
3. Open the document’s Retention tab and use Assign retention schedule / the permitted binding action.
4. Select the approved schedule and confirm the document and business reason.
5. Inspect the resulting obligation, due date and state. Event-triggered schedules may remain pending without a due date.
6. Use Retention calendar and Hold and retention reviews for the applicable follow-up.
7. Before any disposition, inspect all active obligations; a shorter new schedule does not erase a longer existing obligation.
Expected result
The document’s current retention context explains what must be preserved and what evidence controls its due date.Screen 9Document retention after a contextual assignment.Historical application recorded test · illustrative records · business-flow-migration/CUSTODIA_RETENTION_ASSIGNED.png · click to enlarge. Appearance may differ in the installed release.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The document’s current retention context explains what must be preserved and what evidence controls its due date.,documentation/KERNEL_DOCUMENTATION_HUB.html#custodia-demo/step-4-1,,Not run,,,,,,,Not run,
CUSTODIA-04-02,R1-CUSTODIA-04,Custodia,Manage retention and preservation,Module journey,P0,the document’s Retention context or Legal holds and inspect existing overlapping holds.,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | the document’s Retention context or Legal holds and inspect existing overlapping holds. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
A hold protects scoped content from disposal. Pending activation/release can remain protective. A release does not destroy content or remove other obligations.
1. Open the document’s Retention context or Legal holds and inspect existing overlapping holds.
2. Use Create legal hold with the intended scope, reason and required review information.
3. Submit and inspect the hold/task state. Confirm the protective effect in the document context.
4. When the owner authorizes release, use Request hold release with the reason and independent reviewer.
5. The reviewer checks the exact hold and scope and records the eligible decision.
6. Refresh the document and confirm whether other holds or retention obligations remain.
Expected result
Hold history is retained and disposal eligibility is recalculated from all current obligations.Screen 10Held document and its preservation context.Historical application recorded test · illustrative records · business-flow-migration/CUSTODIA_HELD.png · click to enlarge. Appearance may differ in the installed release.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Hold history is retained and disposal eligibility is recalculated from all current obligations.,documentation/KERNEL_DOCUMENTATION_HUB.html#custodia-demo/step-4-2,,Not run,,,,,,,Not run,
CUSTODIA-04-03,R1-CUSTODIA-04,Custodia,Manage retention and preservation,Module journey,P0,Event-based retention and future policy changes,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Event-based retention and future policy changes | 
Who acts | Authorized operator / reviewer | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
An event-triggered assignment cannot start its due-date calculation until its business event is verified. Policy succession changes future assignment choices, not the duration of a prior bound obligation.
1. Create/select an approved event-based policy and bind it to the document.
2. In Retention calendar, locate the pending event and submit the real past/current UTC event date plus evidence reference.
3. The independent reviewer opens Retention event reviews, verifies the event owner/code, evidence and proposed due date and records the decision.
4. Inspect the resulting calendar and obligation. Reject incorrect evidence and submit a corrected request through the supported flow.
5. For a changed policy, use Request retention successor or retirement and obtain the required independent decision.
6. If a successor is future-dated, confirm both the currently effective policy and the scheduled version. Existing assignments keep their recorded policy.
Expected result
Verified events and approved policy versions explain retention dates without shortening existing obligations.
The evidence reference is for reviewer verification; it does not establish an authenticated external event integration. Future event dates, duplicate open event tasks and stale review scope can be rejected.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Verified events and approved policy versions explain retention dates without shortening existing obligations.,documentation/KERNEL_DOCUMENTATION_HUB.html#custodia-demo/step-4-3,,Not run,,,,,,,Not run,
CUSTODIA-04-04,R1-CUSTODIA-04,Custodia,Manage retention and preservation,Module journey,P0,"Disposition readiness and inspect the selected document’s current blockers, retention, holds, versions, exports and archive copies.","Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Disposition readiness and inspect the selected document’s current blockers, retention, holds, versions, exports and archive copies. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Use this flow only for content that the records owner has actually authorized for disposal. Verify it with disposable training content. Document destruction, export-package disposal and archive-copy disposal are distinct scopes.
1. Open Disposition readiness and inspect the selected document’s current blockers, retention, holds, versions, exports and archive copies.
2. Request disposition with the intended scope, independent reviewer and business reason.
3. The reviewer opens Disposition reviews and checks current evidence and eligibility before deciding.
4. After approval, open Disposition requests and use the separately authorized execution action only when offered.
5. Read and enter the exact confirmation required by the form. Verify identity and scope before confirming.
6. Inspect the execution receipt/certificate and activity. An approved request alone is not proof of deletion.
7. For interrupted execution, use the saved request’s Resume action. Preserve a blocked reservation for operator investigation.
Expected result
Canonical completion and its receipt identify the actual disposed scope; history remains available.
A missing storage file by itself is not a valid destruction receipt. Do not manually remove objects or use inactive flags to evade a hold or disposal process.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Canonical completion and its receipt identify the actual disposed scope; history remains available.,documentation/KERNEL_DOCUMENTATION_HUB.html#custodia-demo/step-4-4,,Not run,,,,,,,Not run,
CUSTODIA-05-01,R1-CUSTODIA-05,Custodia,Export and archive governed content,Module journey,P0,"Build, review and download a governed export","Prepare a synthetic document with no personal information, an eligible content class/metadata configuration and authorized capture/reviewer identities. Confirm current processing services before promising a preview or download. Use a recipient you control for sharing demonstrations and a prepared non-destructive record for retention/hold explanations.","Before you act | Required context | 
Screen / entry | Build, review and download a governed export | 
Who acts | Authorized operator / reviewer | 
You need | Prepare a synthetic document with no personal information, an eligible content class/metadata configuration and authorized capture/reviewer identities. Confirm current processing services before promising a preview or download. Use a recipient you control for sharing demonstrations and a prepared non-destructive record for retention/hold explanations. | 
Steps and field guidance
Use Governed exports or the library’s eligible export action. Decide whether the recipient needs original files or rendered redacted pages before submitting the package for review.
1. Select exact eligible document versions and choose the supported representation.
2. Enter purpose and the required review/validity information. Select permitted business metadata fields and audit supplements as needed.
3. Inspect the snapshot scope and limits. The recorded newer export supports up to 16 versions, 24 MiB original bytes, a 256 KiB manifest, 1,000 audit events and at most 16 redacted pages; representation-specific runtime limits also apply.
4. Submit the request. The reviewer opens Export reviews and inspects the exact manifest, representation, fields, purpose and expiry.
5. After approval, use Execute governed export / the available generation action and wait for verified package status.
6. Download through the current authorized action and inspect package identity/checksums and included evidence.
7. If blocked by changed access, redactions or scope, create the required fresh request after resolving the change. Retry does not make stale approval valid.
Expected result
The package is tied to the reviewed snapshot and current release checks; oversized scope fails rather than silently omitting evidence.
Redacted output uses rendered pages and approved masks; original output preserves originals. Private annotations and free-text redaction reasons are not ordinary disclosure supplements. Audit scope is the available history through the request snapshot, not future activity.Screen 11Governed export scope and selectable supplements.Historical application recorded test · illustrative records · delivery-actions/EXPORT_SCOPE.png · click to enlarge. Appearance may differ in the installed release.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The package is tied to the reviewed snapshot and current release checks; oversized scope fails rather than silently omitting evidence.,documentation/KERNEL_DOCUMENTATION_HUB.html#custodia-demo/step-5-1,,Not run,,,,,,,Not run,
CUSTODIA-05-02,R1-CUSTODIA-05,Custodia,Export and archive governed content,Module journey,P0,"Revoke, recover and dispose of an export package","Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Revoke, recover and dispose of an export package | 
Who acts | Authorized operator / reviewer | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Export revocation stops future authorized release. It does not recall downloaded copies. Package disposal removes the specified derived package, not its source documents.
1. Inspect the export state and use Revoke export package when its authority must end.
2. For a recoverable generation interruption, use Resume export generation / the offered recovery action on that same request.
3. For disposal, open Export package disposal and request the eligible revoked/expired package’s removal.
4. The independent reviewer uses Package disposal reviews and checks current source obligations, holds and package identity.
5. Before execution, inspect the current approval and enter DELETE EXPORT PACKAGE only for the intended training/authorized package.
6. Use Resume package deletion after an interruption when offered. Cancellation is available before execution, subject to current state.
7. Verify the package destruction certificate and retained source-document history.
Expected result
The certificate identifies local derived-export-package scope. Originals, backups and downloaded copies are not claimed erased.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The certificate identifies local derived-export-package scope. Originals, backups and downloaded copies are not claimed erased.",documentation/KERNEL_DOCUMENTATION_HUB.html#custodia-demo/step-5-2,,Not run,,,,,,,Not run,
CUSTODIA-05-03,R1-CUSTODIA-05,Custodia,Export and archive governed content,Module journey,P0,"Archive transfers and choose the eligible approved, packaged and unrevoked export.","Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Archive transfers and choose the eligible approved, packaged and unrevoked export. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
The implemented local archive accepts an eligible governed package. External archive destinations require separate provider configuration and acceptance.
1. Open Archive transfers and choose the eligible approved, packaged and unrevoked export.
2. Select the available configured destination, enter purpose and required review information, and submit.
3. The independent reviewer checks destination, package identity, representation and manifest in Archive transfer reviews.
4. After approval, use the separately authorized execution action and its displayed confirmation.
5. Wait for the transfer acknowledgement and integrity result. Inspect the recorded destination and package checksum.
6. If transfer is interrupted, use Resume archive transfer on the same request. Do not create another destination copy merely because the response was lost.
Expected result
An accepted archive copy and its acknowledgement are recorded. The source document and export package remain separate objects.
An archive copy can remain a blocker for source destruction until its own governed disposal is completed. Transfer is not an instruction to remove originals.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",An accepted archive copy and its acknowledgement are recorded. The source document and export package remain separate objects.,documentation/KERNEL_DOCUMENTATION_HUB.html#custodia-demo/step-5-3,,Not run,,,,,,,Not run,
CUSTODIA-05-04,R1-CUSTODIA-05,Custodia,Export and archive governed content,Module journey,P0,the accepted transfer and choose Request archive retrieval.,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | the accepted transfer and choose Request archive retrieval. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Retrieval needs fresh authority for the accepted archive copy. The implementation described here serves the archive requester; it is not arbitrary cross-owner distribution.
1. Open the accepted transfer and choose Request archive retrieval.
2. Enter the new purpose and validity shown by the form; the recorded range is 1–1,440 minutes.
3. Have the separate reviewer inspect Archive retrieval reviews, including source manifest, representation, checksum, purpose and expiry.
4. Open Archive retrievals after approval and use the verified ZIP download.
5. If cancelled, expired or blocked by current source access/redaction changes, resolve that authority before requesting another download.
6. Inspect retrieval activity and retain the archive identity with any downloaded copy.
Expected result
Release is read from the archive and verified against its recorded acknowledgement and current authority.
A fresh eligible archive retrieval can remain possible after its source export expires/revokes. Cancellation prevents new releases; already downloaded copies cannot be recalled.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Release is read from the archive and verified against its recorded acknowledgement and current authority.,documentation/KERNEL_DOCUMENTATION_HUB.html#custodia-demo/step-5-4,,Not run,,,,,,,Not run,
CUSTODIA-05-05,R1-CUSTODIA-05,Custodia,Export and archive governed content,Module journey,P0,"Archive copy disposal and, when authorized and eligible, enter DELETE ARCHIVE COPY to execute.","Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | Archive copy disposal and, when authorized and eligible, enter DELETE ARCHIVE COPY to execute. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Archive-copy disposal is distinct from deleting the source export or original document. Check every obligation and any open retrieval authority first.
1. Select the accepted transfer and choose Request archive disposal.
2. Inspect the exact archive object and request scope; submit with the required reason and independent reviewer.
3. The reviewer opens Archive disposal reviews and checks holds, retention, source access and any pending or approved retrieval.
4. Cancel or allow conflicting retrieval authority to expire through its normal flow before disposal can proceed.
5. Open Archive copy disposal and, when authorized and eligible, enter DELETE ARCHIVE COPY to execute.
6. Use Resume archive deletion for an interrupted reserved operation. Cancellation is limited to the pre-execution state.
7. Verify the archive disposal certificate and retained acknowledgement/history.
Expected result
The certificate covers the specific local archive copy. Original documents, export packages, backups and previously downloaded copies are outside that scope.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The certificate covers the specific local archive copy. Original documents, export packages, backups and previously downloaded copies are outside that scope.",documentation/KERNEL_DOCUMENTATION_HUB.html#custodia-demo/step-5-5,,Not run,,,,,,,Not run,
CUSTODIA-06-01,R1-CUSTODIA-06,Custodia,Recover processing and storage issues,Module journey,P0,"the workspace corresponding to the failed stage and inspect document/version, request reference, reason and last attempt.","Prepare a synthetic document with no personal information, an eligible content class/metadata configuration and authorized capture/reviewer identities. Confirm current processing services before promising a preview or download. Use a recipient you control for sharing demonstrations and a prepared non-destructive record for retention/hold explanations.","Before you act | Required context | 
Screen / entry | the workspace corresponding to the failed stage and inspect document/version, request reference, reason and last attempt. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Prepare a synthetic document with no personal information, an eligible content class/metadata configuration and authorized capture/reviewer identities. Confirm current processing services before promising a preview or download. Use a recipient you control for sharing demonstrations and a prepared non-destructive record for retention/hold explanations. | 
Steps and field guidance
Operations workspaces separate Upload processing, Admission processing and Text processing. Their outcomes must not be treated as interchangeable.
1. Open the workspace corresponding to the failed stage and inspect document/version, request reference, reason and last attempt.
2. Correct the supported cause, such as a missing required value or an available scanner/extractor configuration.
3. Use the offered scan/extract/retry action for eligible records. In a batch, select no more than the displayed supported limit (recorded processing bound: 20).
4. Keep the browser/session open. Pause stops after the current item rather than cancelling a completed storage operation.
5. Inspect completed, blocked and failed items separately. Retry eligible failed work without repeating successful commands.
6. Return to Document processing and refresh stages to verify the outcome.
7. Escalate unknown or unsupported failures with the correlation/request reference, version and time.
Expected result
Recovery retains receipts and history and does not bypass admission or owner policy.
These browser batches are not proof of unattended Scheduler execution. Durable delegated quarantine/index recovery, replacement-file recovery and physical index repair remain broader recorded work.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",Recovery retains receipts and history and does not bypass admission or owner policy.,documentation/KERNEL_DOCUMENTATION_HUB.html#custodia-demo/step-6-1,,Not run,,,,,,,Not run,
CUSTODIA-06-02,R1-CUSTODIA-06,Custodia,Recover processing and storage issues,Module journey,P0,"the selected document’s Storage tab to inspect its recorded objects, integrity and relevant actions.","Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | the selected document’s Storage tab to inspect its recorded objects, integrity and relevant actions. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
The document Storage tab shows custody context. Tenant-level Storage investigations and Storage scan history are operator surfaces. An investigation note cannot authorize deletion.
1. Open the selected document’s Storage tab to inspect its recorded objects, integrity and relevant actions.
2. For an operational finding, open Storage investigations and select its case. Check observed namespace/object identity, current state and latest scan.
3. Inspect Storage scan history to understand the observation window and counts. A later clean observation can mark a finding No longer observed without erasing history.
4. Record a review note with the current evidence and intended follow-up; keep the note factual.
5. Use Verified orphan packages only for eligible verified derived packages and their governed remediation/disposal flow.
6. Retain unknown or changed objects for investigation. Escalate cases that cannot be resolved through a permitted action.
7. After a supported corrective operation, use the next authorized scan/observation to verify the result.
Expected result
Findings, notes and observations remain auditable. Neither a note nor an absent file is a deletion authorization.
The recorded scan recorder is an operator-run process, not a universal self-service Scan button. Recent UI lists are bounded; older persisted history may require operator retrieval. Do not claim unattended cleanup or physical backup sanitization from these screens.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","Findings, notes and observations remain auditable. Neither a note nor an absent file is a deletion authorization.",documentation/KERNEL_DOCUMENTATION_HUB.html#custodia-demo/step-6-2,,Not run,,,,,,,Not run,
CUSTODIA-EX-01,R1-CUSTODIA-07,Custodia,Exception / recovery,Exception / recovery,P0,Upload received but viewer unavailable,"Prepare a synthetic document with no personal information, an eligible content class/metadata configuration and authorized capture/reviewer identities. Confirm current processing services before promising a preview or download. Use a recipient you control for sharing demonstrations and a prepared non-destructive record for retention/hold explanations.","1. Prepare a disposable record exhibiting this condition: Upload received but viewer unavailable.
2. Inspect processing/admission/quarantine and current access.
3. Reopen the affected record and its history; verify: Do not mark the business evidence accepted merely because upload completed.
4. Record actual outcome and supporting record/version or denial evidence.",Do not mark the business evidence accepted merely because upload completed.,documentation/KERNEL_DOCUMENTATION_HUB.html#custodia-manual/decision-guide,,Not run,,,,,,,Not run,
CUSTODIA-EX-02,R1-CUSTODIA-07,Custodia,Exception / recovery,Exception / recovery,P0,Business reviewer sees old content,"Prepare a synthetic document with no personal information, an eligible content class/metadata configuration and authorized capture/reviewer identities. Confirm current processing services before promising a preview or download. Use a recipient you control for sharing demonstrations and a prepared non-destructive record for retention/hold explanations.","1. Prepare a disposable record exhibiting this condition: Business reviewer sees old content.
2. Compare exact linked document version/hash.
3. Reopen the affected record and its history; verify: Create a governed new business review when replacing reviewed evidence.
4. Record actual outcome and supporting record/version or denial evidence.",Create a governed new business review when replacing reviewed evidence.,documentation/KERNEL_DOCUMENTATION_HUB.html#custodia-manual/decision-guide,,Not run,,,,,,,Not run,
CUSTODIA-EX-03,R1-CUSTODIA-07,Custodia,Exception / recovery,Exception / recovery,P0,Metadata correction requested,"Prepare a synthetic document with no personal information, an eligible content class/metadata configuration and authorized capture/reviewer identities. Confirm current processing services before promising a preview or download. Use a recipient you control for sharing demonstrations and a prepared non-destructive record for retention/hold explanations.","1. Prepare a disposable record exhibiting this condition: Metadata correction requested.
2. Use the metadata lifecycle for the selected document.
3. Reopen the affected record and its history; verify: Do not replace file bytes just to correct a label.
4. Record actual outcome and supporting record/version or denial evidence.",Do not replace file bytes just to correct a label.,documentation/KERNEL_DOCUMENTATION_HUB.html#custodia-manual/decision-guide,,Not run,,,,,,,Not run,
CUSTODIA-EX-04,R1-CUSTODIA-07,Custodia,Exception / recovery,Exception / recovery,P0,Recipient cannot open link,"Prepare a synthetic document with no personal information, an eligible content class/metadata configuration and authorized capture/reviewer identities. Confirm current processing services before promising a preview or download. Use a recipient you control for sharing demonstrations and a prepared non-destructive record for retention/hold explanations.","1. Prepare a disposable record exhibiting this condition: Recipient cannot open link.
2. Check scope, validity, identity and current document access.
3. Reopen the affected record and its history; verify: Do not broaden sharing to everyone to mask an identity mismatch.
4. Record actual outcome and supporting record/version or denial evidence.",Do not broaden sharing to everyone to mask an identity mismatch.,documentation/KERNEL_DOCUMENTATION_HUB.html#custodia-manual/decision-guide,,Not run,,,,,,,Not run,
CUSTODIA-EX-05,R1-CUSTODIA-07,Custodia,Exception / recovery,Exception / recovery,P0,Disposition blocked,"Prepare a synthetic document with no personal information, an eligible content class/metadata configuration and authorized capture/reviewer identities. Confirm current processing services before promising a preview or download. Use a recipient you control for sharing demonstrations and a prepared non-destructive record for retention/hold explanations.","1. Prepare a disposable record exhibiting this condition: Disposition blocked.
2. Inspect holds, retention and outstanding owner obligations.
3. Reopen the affected record and its history; verify: Soft deletion is not authority to destroy content.
4. Record actual outcome and supporting record/version or denial evidence.",Soft deletion is not authority to destroy content.,documentation/KERNEL_DOCUMENTATION_HUB.html#custodia-manual/decision-guide,,Not run,,,,,,,Not run,
MEDES-01-01,R1-MEDES-01,MEDES,Open a case and receive evidence,Module journey,P0,"MEDES → Members and cases → Member context, or use Client Information / Related Documents where that entry is available.","Use a fictional member/case under approved tenant/domain access, eligible case operator and independent reviewer identities, admitted test documents and published Pulse content. Confirm current recipient/provider configuration and worker readiness for the exact channel being verified. Prepare a safe completed record for features whose live provider prerequisite remains parked.","Before you act | Required context | 
Screen / entry | MEDES → Members and cases → Member context, or use Client Information / Related Documents where that entry is available. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Use a fictional member/case under approved tenant/domain access, eligible case operator and independent reviewer identities, admitted test documents and published Pulse content. Confirm current recipient/provider configuration and worker readiness for the exact channel being verified. Prepare a safe completed record for features whose live provider prerequisite remains parked. | 
Steps and field guidance
Use Members and cases to establish the correct person and exchange before processing documents. MEDES links current member information from its authorized source. It does not use the case screen to overwrite the source member facts.
Find a member and link the current context
1. Open MEDES → Members and cases → Member context, or use Client Information / Related Documents where that entry is available.
2. Search by the member name or number. Review the returned identity, number, source and Updated timestamp.
3. Open the member. If Link member is available, enter a meaningful Reason and confirm Link member.
4. Verify Member reference updated. The member reference can now be selected by document upload/indexing when your current permissions allow it.
5. If you are authorized to create a case, choose Start case from this member or New case from Exchange cases.
Create an exchange case
1. Open Exchange cases and choose New case.
2. Use Find member to search the authorized member source. Select the correct person by name and member number.
3. Choose Priority: Low, Normal, High or Urgent. Enter the required Reason for starting the exchange.
4. Choose Create case. If confirmation is interrupted, use Retry same action.
5. Open the resulting case and check its number, member, priority and status. Retain the case number as the reference for document and communication work.
Field | Source / purpose | What to check | 
Member / Member number | Current authorized member source, used to identify the person. | Match both before creating the case. | 
Member information updated | Timestamp of the member reference used by MEDES. | A changed source reference must be refreshed before further work. | 
Priority | Your selected business urgency for a new case. | Choose an accurate value; urgency does not bypass reviews. | 
Reason | Your explanation, recorded with the operation. | Describe why this case or linkage is needed; maximum 2,000 characters. | 
Case number / Status | Assigned or maintained by the case workflow. | Use the number for navigation; follow the state’s available actions. | 
Continue work from a case
• Show documents expands the member’s documents that you are permitted to read. Open the appropriate document; unrelated or restricted records are not made available by the expansion.
• View messages and Send message carry the case/member context into secure messaging.
• Respond to customer opens an activity that tracks follow-up and confirmed response evidence.
• Open case review leads to the case task or to Start case review if no current review has been started.
• When Member information changed appears, return to Member context and refresh/link the current reference. Dependent actions remain blocked until the source is current.
Existing case search: Search Exchange cases by the available case/member criteria before creating another case. If a record is missing, first check your domain, profile and member access. Creating a duplicate does not resolve a permission problem.Screen 1Create an exchange case for the selected current member.Historical application recorded test · illustrative records · member-case/member-case-create.png · click to enlarge. Appearance may differ in the installed release.
Check before continuing: The case has a saved number, the correct current member reference, priority and state.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The case has a saved number, the correct current member reference, priority and state.",documentation/KERNEL_DOCUMENTATION_HUB.html#medes-demo/step-1-1,R1-G02; R1-G03; R1-G04,Not run,,,,,,,Not run,
MEDES-01-02,R1-MEDES-01,MEDES,Open a case and receive evidence,Module journey,P0,MEDES → Documents → Documents / Search Documents.,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | MEDES → Documents → Documents / Search Documents. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Search existing evidence
1. Open MEDES → Documents → Documents / Search Documents.
2. Enter Document name or file name. Set Document access to All my accessible documents, My uploads or Assigned to me.
3. Narrow Business review and the Received from / Received through date range as needed, then run the search.
4. Open the document row. Check its title, Access, Business review, version and security admission before using its content.
5. Select the available tab: Details, View document, Metadata or History. Owned documents may also show Processing, Security, Retention and Storage.
The search is scoped to your accessible documents, including your uploads and assigned reviews. It is not an unrestricted search of every repository object. Some original entries such as Search Results, Document Viewer, View Metadata and Document History open the same document workspace at a different tab.
Upload files
1. Open Upload documents. In Select Files, choose files or drag them into the upload area.
2. Remove unwanted files before continuing. Confirm the selected files and choose Continue.
3. In Enter Details, select the approved content class/type and review the title for each document. The selected class can restrict size and formats further.
4. Set Related to to Existing business context or No direct link. For an existing context, use Search contexts, select Business context and verify the selected reference.
5. Enter the Received date and optional Description. The date must be valid and not in the future. These business details apply to every file in the batch.
6. Choose Continue to review the files and their shared business details. Return with Back if they are wrong.
7. Choose Upload [number] Files. The queue stores one file at a time and reports the result per file.
8. If necessary, choose Pause Queue; it pauses after the current file. Use Retry Remaining Files for unconfirmed/failed files in the same dialog.
9. Choose Done or View uploads and verify each stored record. A successful upload begins Custodia screening; continue only when the relevant content is admitted.
Input or limit | Current candidate behavior | 
Formats | PDF, DOCX, DOC, PNG, JPEG, TIFF, text and ZIP, subject to the approved content class. Upload acceptance does not guarantee every format can be previewed or split. | 
File size | 1 byte to 25 MiB per file; the approved class may impose a lower maximum. | 
Batch size | Up to 20 files and 100 MiB in total. A secure-upload request can impose a lower file count. | 
Filename / title | Filename up to 180 characters; no path separators or control characters. Document title up to 200 characters. | 
Received date | The date evidence was received; future dates are rejected. | 
Description | Optional, up to 500 characters. Applies to the batch. | 
Business context | A current existing reference available to the selected profile. A case-linked upload keeps the case context fixed. | 
Follow upload results
Upload state | Meaning | Next action | 
PREPARED | The upload request exists but storage has not been confirmed. | Resume/retry the saved upload request. | 
UPLOAD_FAILED | The storage step did not complete. | Read the error and retry the remaining file in the existing dialog. | 
STORED | Storage has a confirmed receipt. | Check security screening, then begin intake. | 
QUARANTINED | Content is waiting for admission or requires attention. | Inspect the custody result; ask the content administrator if it does not progress. | 
ADMITTED | Content is available for the permitted next operations. | Proceed to intake/indexing and independent review as required. | 
Metadata, viewing and history
Metadata fields come from the approved Custodia schema for the selected content class. Their labels and required values can differ by document type. Complete the fields shown rather than inventing an unrelated value. Editing requires separate permission and an editable version.
After a document version has been submitted for review, its metadata can be locked to preserve the reviewed evidence. Correct that evidence using a replacement upload and a linked new review. History identifies recorded events and sources; a document’s business history and file security history describe different parts of its lifecycle.
Viewing, downloading and printing follow the current document grant. A review preview does not imply download/print permission. If content access is unavailable, ask the owner to check the exact version, purpose and grant expiry instead of copying the file through another channel.
Check before continuing: The authorized document list and selected document show the intended member/case, version, access, admission and business-review state.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The authorized document list and selected document show the intended member/case, version, access, admission and business-review state.",documentation/KERNEL_DOCUMENTATION_HUB.html#medes-demo/step-1-2,R1-G02; R1-G03; R1-G04,Not run,,,,,,,Not run,
MEDES-01-03,R1-MEDES-01,MEDES,Open a case and receive evidence,Module journey,P0,MEDES → Documents → Document Intake Queue,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | MEDES → Documents → Document Intake Queue | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Triage a received document
1. Open MEDES → Documents → Document Intake Queue. Search by Document name or file name and Intake status, then choose Search intake.
2. Open a New record, inspect its document and select Begin intake. Enter Decision reason and choose Save intake decision.
3. Inspect all of the available source content. For one complete document choose Confirm single document. For a packet containing multiple documents choose Mark for splitting.
4. Enter the reason for the selected decision and save it. Reject intake is available for the allowed nonterminal intake states when evidence cannot be processed.
5. For Ready for indexing, choose Classify and index. For Needs splitting, choose Split document packet.
Current intake state | Permitted path shown by the workflow | 
New | Begin intake → Intake in progress; or Reject intake with a reason. | 
Intake in progress | Confirm single document → Ready for indexing; Mark for splitting → Needs splitting; or Reject intake. | 
Needs splitting | Complete a verified split; or Reject intake while permitted. | 
Split into documents | The original packet is preserved. Process each admitted child document. | 
Ready for indexing | Complete metadata and context in Classify and index. | 
Rejected | Read the recorded reason and follow the replacement process; the prior record remains in history. | 
Split a PDF packet
1. Open a permitted, unreviewed PDF packet marked Needs splitting. Select Split document packet.
2. Open the viewer and verify the actual page count. The split form uses that confirmed count.
3. Enter New document title and Include pages [start] through [end] for the first child, then choose Add document.
4. Repeat in page order. Every page must belong to exactly one contiguous group. Use Edit last document to correct the latest group.
5. Verify that all pages are assigned to at least two documents. Enter Split reason.
6. Choose Create documents from pages. If interrupted, choose Retry saved split to preserve the same groups and child identities.
7. Review the child records and their custody state. When a child is admitted and accessible, open its intake and continue indexing. Keep the original packet for traceability.
PDF limits and preparation: The split contract supports 2–200 source pages and 2–40 child groups, with a title of up to 200 characters per child. Signed, interactive, annotated or protected/redacted sources need an appropriately approved flattened source before splitting. The application blocks operations that would lose protected overlays. Obtain that source through the document owner; do not discard security markings.
Classify and confirm indexing
1. Open Classify and index from the intake record. Confirm the intake is Ready for indexing.
2. Open Document metadata and complete the current approved schema. The required document type, category, source channel and other class-specific values must be present.
3. Inspect Confidentiality. It reflects Custodia classification and current permissions; this tab is not a way to weaken the content policy.
4. Return to Indexing. Search and choose the current Business context, then enter Indexing reason.
5. Choose Confirm indexing. Verify Indexing confirmed / Indexed before requesting review.
6. Choose Request independent review when available. If metadata or context changes later, review the current values and confirm indexing again when Needs rechecking is shown.
Indexing state | Meaning | Resolution | 
Needs metadata / NOT_READY | Required schema or values are missing. | Complete metadata; an administrator must publish a missing schema. | 
Ready to confirm / READY | Evidence can be checked for indexing. | Confirm the current business context and reason. | 
Indexed / INDEXED | The metadata/context evidence was confirmed. | Request review when the custody grant and workflow are ready. | 
Needs rechecking / STALE | Metadata or linked context changed. | Inspect the new values and reconfirm; do not rely on the old confirmation. | 
Screen 2Indexed document ready to request independent review. The sample uses an existing case reference.Historical application recorded test · illustrative records · document-operations/indexing-complete.png · click to enlarge. Appearance may differ in the installed release.Screen 3Split plan: named child documents and the original PDF page ranges.Historical application recorded test · illustrative records · document-splitting/split-plan.png · click to enlarge. Appearance may differ in the installed release.
Check before continuing: The original and any split child documents remain linked; indexing and the independent-review stage are visible.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The original and any split child documents remain linked; indexing and the independent-review stage are visible.,documentation/KERNEL_DOCUMENTATION_HUB.html#medes-demo/step-1-3,R1-G02; R1-G03; R1-G04,Not run,,,,,,,Not run,
MEDES-02-01,R1-MEDES-02,MEDES,Request evidence from a named external partner,Module journey,P0,MEDES → Documents → Secure Upload Workspace and choose Request documents.,"Use a fictional member/case under approved tenant/domain access, eligible case operator and independent reviewer identities, admitted test documents and published Pulse content. Confirm current recipient/provider configuration and worker readiness for the exact channel being verified. Prepare a safe completed record for features whose live provider prerequisite remains parked.","Before you act | Required context | 
Screen / entry | MEDES → Documents → Secure Upload Workspace and choose Request documents. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Use a fictional member/case under approved tenant/domain access, eligible case operator and independent reviewer identities, admitted test documents and published Pulse content. Confirm current recipient/provider configuration and worker readiness for the exact channel being verified. Prepare a safe completed record for features whose live provider prerequisite remains parked. | 
Steps and field guidance
Secure upload is a named-recipient workflow. The recipient signs in with an eligible active account and authorized profile. Copying a request link does not make it an anonymous upload link or grant another person access.
Receiving team: create a request
1. Open MEDES → Documents → Secure Upload Workspace and choose Request documents.
2. Use Find recipient to search active accounts with approved secure-upload access. Choose the intended Recipient.
3. Set Maximum files between 1 and 20 and Expires in hours between 1 and 168.
4. Enter Requested documents and reason, explaining the required evidence clearly. Create the request.
5. Open the saved request. Use Copy link to share its recipient-bound link through an authorized channel. Notifications depend on the published Pulse setup.
6. Track the request and submitted files. Do not treat a copied link or notification as proof of submission.
Named recipient: upload and submit
1. Open the request link and sign in using the named recipient’s account and an authorized profile.
2. Read the requested evidence, maximum file count and expiry.
3. Choose Upload files and complete the upload wizard. The files remain attached to this request; the receiving team assigns the business context during indexing.
4. Return to the request and verify the uploaded files. Enter Action reason and choose Submit documents when the submission is complete.
5. Verify Submitted. Refresh later to see the receiving team’s progress. Uploading files alone does not submit the completed file set.
Receiving team: accept into intake
1. Open a Submitted request and inspect each file’s security state.
2. When all files have passed screening and are available to your profile, enter Action reason and choose Begin intake.
3. Verify Accepted, then open each available file’s intake. Perform triage, splitting if needed, indexing and independent review.
4. If the submission is unusable, use Reject submission with an explanation. A rejected/expired request requires a new request for corrected files.
5. Use Close request where permitted when no further upload should be accepted. The request history remains visible to its participants.
State | What the user should do | 
OPEN | Recipient uploads the requested files and submits the completed file set. | 
SUBMITTED | Receiving team waits for complete admission and begins intake. | 
ACCEPTED | Receiving team completes intake/indexing of the files. This is not case or eligibility approval. | 
REJECTED | Read the recorded reason; request a new submission link for corrections. | 
REVOKED | The receiving team closed the request. No further upload is accepted. | 
EXPIRED | Ask the receiving team for a new request. | 
Screen 4Named-recipient secure upload request. The pictured localhost link is a recorded test example; use the link created in your own environment.Historical application recorded test · illustrative records · secure-upload/secure-upload-request.png · click to enlarge. Appearance may differ in the installed release.
Check before continuing: The request is addressed to the intended eligible recipient with its expiry and purpose. Any accepted upload is linked to its request and case; missing or expired access remains blocked.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The request is addressed to the intended eligible recipient with its expiry and purpose. Any accepted upload is linked to its request and case; missing or expired access remains blocked.,documentation/KERNEL_DOCUMENTATION_HUB.html#medes-demo/step-2-1,R1-G02; R1-G03; R1-G04,Not run,,,,,,,Not run,
MEDES-03-01,R1-MEDES-03,MEDES,Review evidence and complete case work,Module journey,P0,Document reviews → Requested by me to track the submission,"Use a fictional member/case under approved tenant/domain access, eligible case operator and independent reviewer identities, admitted test documents and published Pulse content. Confirm current recipient/provider configuration and worker readiness for the exact channel being verified. Prepare a safe completed record for features whose live provider prerequisite remains parked.","Before you act | Required context | 
Screen / entry | Document reviews → Requested by me to track the submission | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Use a fictional member/case under approved tenant/domain access, eligible case operator and independent reviewer identities, admitted test documents and published Pulse content. Confirm current recipient/provider configuration and worker readiness for the exact channel being verified. Prepare a safe completed record for features whose live provider prerequisite remains parked. | 
Steps and field guidance
A document review applies to an exact admitted version. It requires an eligible independent reviewer, an approved Custodia preview grant with an appropriate purpose, and the published Regulix review configuration. The assignment itself does not supply document access.
Request review as the document owner
1. Complete intake and indexing. Open the upload, indexed document or correspondence archive that is ready for review.
2. Choose Request independent review. Select Reviewer and approved purpose from the available grant choices.
3. Enter Review reason, up to 2,000 characters, stating what the reviewer should assess.
4. Choose Submit for review. If confirmation is interrupted, use Retry review request.
5. Open Document reviews → Requested by me to track the submission. If it shows a saved handoff, choose Resume review submission rather than submitting a duplicate review.
No eligible reviewer grant: Ask the document owner or Custodia administrator to establish the correct approved preview grant for a different reviewer and the exact admitted version. Then choose Refresh reviewers. A role name or task assignment alone is insufficient.
Review as the independent reviewer
1. Open Document reviews, set Reviews to Assigned to me and select Open reviews. A notification may open the same exact review.
2. Open the review and inspect its reason, due time, document identity and current access.
3. View the document through the available preview. For correspondence, also inspect the case, recipient, delivery channel and destination alongside the complete PDF.
4. Select Decision: Approve document / Approve correspondence delivery, Return for correction, or Reject document.
5. Enter Decision comments explaining the outcome. Choose Confirm decision.
6. Verify the recorded review state and comments. If the decision was saved but confirmation failed, use Resume decision.
Outcome | Meaning | Owner’s next step | 
APPROVED | Independent review approved the exact evidence/version and, for a letter, the exact fulfillment information. | Continue the permitted business workflow or delivery preparation. | 
RETURNED | Corrections are required. | Read the comments; provide a new linked replacement or corrected correspondence draft. | 
REJECTED | The reviewer rejected the submitted evidence. | Read the reason and follow the authorized business resolution. Do not rewrite the original decision. | 
AWAITING_START | The request exists, but its workflow handoff is not confirmed. | Resume the existing submission with the permitted owner action. | 
IN_REVIEW | An active independent review is in progress. | The assigned eligible reviewer completes it. | 
Replace a returned document
1. Open Requested by me → Awaiting correction, or use the Corrections and returned reviews entry.
2. Read the decision comments before changing anything.
3. Choose Upload replacement and upload corrected evidence in the same business context. Complete its required admission/intake/indexing steps.
4. Return to the original returned review and choose Submit replacement for review.
5. Choose a new admitted upload without an existing review, select its eligible reviewer/purpose, and submit with a reason.
6. Check the new review and its link to the previous review. The old file and decision remain in history.
Correct a returned generated letter
For a correspondence review, choose Open letter for correction. In the letter, select Prepare corrected letter. This creates a separate draft linked to the prior review. Correct it, save it, generate a new PDF and repeat packet preparation, archiving and independent review. Approval of the old PDF does not approve the replacement.
If the review period has ended or document access was revoked, contact the document owner. If the current profile has no permitted decision, switch to the correctly assigned reviewer profile; do not attempt self-approval. Document review history is accessed through the review queue’s completed/all filters and the linked review records.
Check before continuing: The decision references the intended saved document/version; a returned item remains available for correction.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The decision references the intended saved document/version; a returned item remains available for correction.,documentation/KERNEL_DOCUMENTATION_HUB.html#medes-demo/step-3-1,R1-G02; R1-G03; R1-G04,Not run,,,,,,,Not run,
MEDES-03-02,R1-MEDES-03,MEDES,Review evidence and complete case work,Module journey,P0,the correct exchange case and confirm that the member reference is current.,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | the correct exchange case and confirm that the member reference is current. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
The case workflow carries reviewed evidence into case review and then eligibility review. The eligibility stage uses an independent eligible worker; completing an earlier stage does not authorize the same person to approve the next independent stage.
Start case review
1. Open the correct exchange case and confirm that the member reference is current.
2. Complete the required document reviews first. Choose Open case review.
3. If the case has no current review, enter Review reason and choose Start case review.
4. Verify that the workflow handoff has completed and the case work record opens. If interrupted, use Retry saved start.
5. Read Review stage, Task status, Assigned to, Priority, Due and Editing before deciding what to do.
Find and claim work
1. Open MEDES → Case work → Work Queue.
2. Choose Queue: My work or Available to claim. Supervisors with the appropriate permission can use All authorized work.
3. Optionally filter Find work, Review stage and Task status; choose Apply filters.
4. Open the task. Check the case/member and the current stage.
5. Choose Claim when offered, enter Action reason and confirm. Verify your assignment before performing the review.
6. Use Open case and documents to inspect the supporting case and evidence.
Choose the correct task action
Action | Use and expected result | 
Claim | Take an available task that the current profile is eligible to own. | 
Release | Give up the current assignment so another eligible worker can take it. | 
Hold | Pause current work with a reason; the task shows On hold. | 
Resume | Continue work after the reason for its pause has been resolved. | 
Request information | Record that more information is needed. Use a secure message or customer-support activity for the follow-up; this action is not itself a completed customer response. | 
Escalate | Record the reason the task requires supervisor attention. | 
Reassign | An authorized supervisor chooses an eligible assignee and records a reason. Eligibility and current member access are checked. | 
Lock / Unlock | An authorized supervisor controls editing of the current work item. Unlocking does not grant additional business permissions. | 
Complete case review | Record completion of the case stage and advance to eligibility review when its workflow conditions are met. | 
Record eligibility decision | Complete the independent eligibility stage using an outcome, effective date, evidence checklist and reason. | 
Cancel interrupted action | Authorized recovery of a pending action where offered. Inspect the saved request and history before using it. | 
Only actions allowed by your role, assignment and the current record state appear. Most task actions require a reason of up to 2,000 characters. The task history preserves the action, reason and recorded time.
Record an eligibility decision
1. As the independently eligible reviewer, open an available Eligibility review task and claim it if required.
2. Inspect the case, current member context and reviewed documents. Verify that the earlier case-review stage has completed.
3. Choose Record eligibility decision.
4. Select Eligibility outcome: Approved or Denied. Enter the required Effective date.
5. Complete the Evidence reviewed checklist: Identity, Residency, Citizenship, Income and Medical records. Check each only after carrying out the applicable review.
6. Enter Decision reason and confirm Record eligibility decision.
7. Verify the final Eligibility decision panel, recorded outcome/date/reason and completed workflow checkpoint. The result is a MEDES decision; it does not overwrite member-source facts.
Recover interrupted work
Saved action awaiting confirmation means that the application has retained a specific request. Use Retry saved action, or Refresh task to inspect its current result. Repeatedly creating new requests can obscure which outcome is current. If the task is locked or no longer assigned to you, ask the supervisor to resolve the assignment. No due date set means a deadline was not recorded; it does not mean that a service-level target was met.
Screen 5Eligibility task with outcome, effective date, evidence checklist and decision reason. The implementation requires the applicable form checks before confirmation.Historical application recorded test · illustrative records · work-queues/work-eligibility-checklist.png · click to enlarge. Appearance may differ in the installed release.
Check before continuing: The assigned task records the permitted outcome and supporting evidence against the correct case.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The assigned task records the permitted outcome and supporting evidence against the correct case.,documentation/KERNEL_DOCUMENTATION_HUB.html#medes-demo/step-3-2,R1-G02; R1-G03; R1-G04,Not run,,,,,,,Not run,
MEDES-04-01,R1-MEDES-04,MEDES,"Communicate, generate correspondence and follow delivery",Module journey,P0,MEDES → Secure messages → Inbox / Secure Messages.,"Use a fictional member/case under approved tenant/domain access, eligible case operator and independent reviewer identities, admitted test documents and published Pulse content. Confirm current recipient/provider configuration and worker readiness for the exact channel being verified. Prepare a safe completed record for features whose live provider prerequisite remains parked.","Before you act | Required context | 
Screen / entry | MEDES → Secure messages → Inbox / Secure Messages. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Use a fictional member/case under approved tenant/domain access, eligible case operator and independent reviewer identities, admitted test documents and published Pulse content. Confirm current recipient/provider configuration and worker readiness for the exact channel being verified. Prepare a safe completed record for features whose live provider prerequisite remains parked. | 
Steps and field guidance
Secure messages are application conversations. Email notifications can alert a recipient, but the message is read inside the authorized workspace. Messages can link to a document, member, case or task without changing access to that underlying record.
Read and organize messages
1. Open MEDES → Secure messages → Inbox / Secure Messages.
2. Choose the appropriate folder: Inbox, Sent, Drafts, Archived or Trash where available.
3. Use Find messages to search the subject, message or sender. Additional filters include sender, priority, read/responded status, attachments, read-receipt request, recent period and sort order.
4. Open the conversation and read its sender, recipients, content and linked context.
5. Open a linked case or document only through an available action. A restricted attachment requires a current owner grant.
6. Use Mark as read / Mark as unread, archive, trash or restore actions as permitted. Folder organization affects your mailbox; it does not erase the shared audit record.
Compose a secure message
1. Choose Compose message / Send message, or start from a document or case so the relevant context is already linked.
2. Add To recipients. You may also add CC recipients. Search Recipient type as People, Role audience or Workgroups.
3. Select only the intended current audience. The recipient list records the resolved audience at send time; it is not a permanent grant to anyone who later joins a role.
4. If needed, use Choose related record to select Case, Member or My task. Recipients must have the applicable current member access for a linked conversation.
5. Enter Subject, Priority and Message. Enable Request read receipts if required.
6. Use Choose documents to attach permitted admitted documents. Review the complete recipient and attachment list.
7. Choose Save draft to pause privately, or Send message to record the message and recipients.
8. Verify the sent conversation. If confirmation is interrupted, use Retry saved action. Check the Sent folder before creating another message.
Field / limit | Significance | 
To / CC | Up to 20 selected recipient entries. Choose People, Role audience or Workgroups from the eligible directory results. | 
Subject | Required for a new message; up to 200 characters. | 
Message | Required text; up to 10,000 characters. | 
Documents | Up to 10 linked documents. Existing custody/access rules continue to apply. | 
Priority | Helps recipients prioritize the conversation; it does not change authorization. | 
Read receipts | Requests a recorded read indication; it is not a case decision or evidence of external email receipt. | 
Related record | The selected case/member/task context. Remove it before sending only when the message should be independent of that context. | 
Reply, reply all and forward
Command | Audience and behavior | 
Reply to [sender] | Responds to the sender of the selected message. | 
Reply all | Uses the selected message’s sender and recipients. Participants in other private replies are excluded. | 
Forward | Copies the selected message into a new conversation. Choose documents separately when needed and recheck the authorized user. | 
Save / edit draft | Stores a private draft that can be opened from Drafts. A saved draft has not been sent. | 
Discard draft | Removes the unsent saved draft through the permitted action. | 
Partner mailbox and sender permissions
Partner Mailbox uses the secure-message workspace with an additional tenant entitlement. It is not a general public partner portal. If it is unavailable, the administrator must check both the module feature entitlement and the profile’s message permissions.
The proposed sender role set is State User, Case Worker, Eligibility Specialist, Document Reviewer, Support Agent and Supervisor. The other MEDES role definitions are not automatically secure-message senders. Letter-generation and external-delivery permissions are separate from this secure-message sender rule.
Screen 6Compose a secure message with recipients, document references and optional read receipts.Historical application recorded test · illustrative records · secure-messaging/message-compose.png · click to enlarge. Appearance may differ in the installed release.
Check before continuing: The saved or sent message has the intended case context, resolved permitted recipients and authorized document links. A draft is not counted as sent; sending is not a recipient acknowledgment.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The saved or sent message has the intended case context, resolved permitted recipients and authorized document links. A draft is not counted as sent; sending is not a recipient acknowledgment.",documentation/KERNEL_DOCUMENTATION_HUB.html#medes-demo/step-4-1,R1-G02; R1-G03; R1-G04,Not run,,,,,,,Not run,
MEDES-04-02,R1-MEDES-04,MEDES,"Communicate, generate correspondence and follow delivery",Module journey,P0,MEDES → Correspondence → Published correspondence templates for the published MEDES generation choices.,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | MEDES → Correspondence → Published correspondence templates for the published MEDES generation choices. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Correspondence is tied to an authorized case and current member reference. The document is generated from a reviewed, published MEDES Pulse template. Its recipient, channel, exact PDF and any attachments must complete the required review before external delivery.
Find templates and existing correspondence
1. Open MEDES → Correspondence → Published correspondence templates for the published MEDES generation choices.
2. For authoring or governance, use MEDES settings → Communications to open Pulse Letter templates, Email templates or the relevant review workspace if your profile has access.
3. Use On-demand correspondence or Fax correspondence to locate existing work by case, recipient or letter name.
4. Open a letter to inspect Letter and recipient, generated PDF state, Independent review and Delivery history.
5. Use Pending correspondence for items without confirmed completion and Transmission details for the exact delivery record.
Which template is needed?: A Pulse letter template produces the business PDF. A Pulse email notification template produces an alert and its action link. A Vista report template produces a report output. These are different catalogs. MEDES generation lists only eligible published MEDES letter templates; a draft or another module’s template is not a generation choice.
Create a letter or fax cover
1. Open Generate a letter or Create fax cover, or choose Generate letter from correspondence.
2. Use Find a case, choose the correct authorized case and verify its member. A stale member reference must be refreshed first.
3. Select Published letter template and check its current published version.
4. Choose Delivery channel: Fax, Email or Print and mail. The dedicated fax-cover view keeps Fax selected.
5. Enter Recipient name and the destination fields appropriate to the channel. Check the address printed on the letter as well as the electronic destination.
6. For fax, complete the cover fields and notification preferences described below.
7. Optionally choose case-document attachments and put them in the intended order.
8. Choose Save draft if incomplete. When all required inputs are correct, choose Generate PDF.
9. Wait for the generated PDF to become Ready. Use Refresh to check its progress, then Download verified PDF if your action permissions permit it.
Channel | Required destination information | Validation / practical check | 
Fax | Recipient name, US fax number and address printed on the letter. | Use +1 followed by the 10-digit number, for example +15125550101. Verify the actual recipient; the example is not a delivery destination. | 
Email | Recipient name, recipient email and address printed on the letter. | Use the intended authorized mailbox. A generated PDF is not automatically emailed. | 
Print and mail | Recipient name, street address, city, two-letter US state and ZIP code. | The implementation uses US postal addresses; ZIP supports five digits or ZIP+4. Verify the physical address and return-address configuration. | 
Fax cover field reference
Field | Meaning | 
Subject / reference | Required cover subject, up to 200 characters. Use a meaningful business reference. | 
Department / Attention to | Optional routing information for the receiving organization, up to 200 characters each. | 
Cover comments | Optional cover instructions, up to 2,000 characters. | 
Priority | Normal, High or Urgent. | 
Confidentiality | Standard, Sensitive or Restricted; review this together with the applicable document policy. | 
Include confidentiality notice | Controls inclusion of the cover notice. It does not replace content-access controls. | 
Notify me on delivery / failure | Records your delivery-notification preferences; approved Pulse notification setup is required. | 
Sender | Taken from the current account rather than arbitrary typed sender identity. | 
Cover text and correspondence reply text do not accept template-token braces. Enter the final business text; template authoring and placeholder configuration belong in the published Pulse template.
Save, reopen and discard a draft
1. Choose Save draft after selecting a case and entering the available details.
2. Open My drafts in the correspondence workspace to find the saved private draft.
3. Open Edit draft and verify the case, template, destination and attachments. Save changes before generating a PDF from an already-saved draft.
4. Choose Generate PDF only after the edited draft is saved. The generated item is a separate durable result.
5. If the unsent draft is no longer needed, choose Discard draft and Confirm discard. This does not send a letter. Keep draft cancels the discard.
Assemble an attachment packet
1. In Case document attachments choose up to 10 admitted, accessible PDF documents from the case.
2. Use Up, Down and Remove to set the order. The generated letter comes first, followed by the selected documents.
3. Generate the letter and wait for its PDF. When prompted, choose Assemble packet.
4. Verify the complete packet page count and inspect its PDF before requesting review.
5. If assembly was interrupted, choose Retry packet assembly. If an attachment version or access changed, refresh access or prepare a new letter with current documents.
Packet assembly preserves the original source versions. Encrypted, signed, interactive or annotated PDFs require an appropriately approved flattened copy. The exact selected versions must remain available through preparation, review and delivery. Do not treat the unassembled letter as approval of the complete packet.
Archive and independently approve the exact PDF
1. In Document archive select an approved PDF Content class and enter Document title.
2. Choose Archive generated PDF. If a prepared archive is pending, use Retry same archive request.
3. Verify PDF stored and the custody state. Choose Open document intake to complete the required intake, metadata and indexing.
4. When the archive is Admitted and Indexed, choose Request independent review.
5. Select the approved reviewer/purpose, enter the reason and submit. The independent reviewer checks the exact complete PDF, recipient, case, channel and destination.
6. After approval, return to the letter and verify Ready for delivery. Only then select the provider connection and queue external delivery.
7. If returned, use Prepare corrected letter and create a new reviewed version linked to the original review.
Screen 7Generated correspondence packet. PDF Ready and Not archived show why delivery is not yet permitted.Historical application recorded test · illustrative records · correspondence/complete-packet.png · click to enlarge. Appearance may differ in the installed release.
Check before continuing: The exact generated document, recipient and channel are inspected; required case-specific review remains separate from template publication.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.","The exact generated document, recipient and channel are inspected; required case-specific review remains separate from template publication.",documentation/KERNEL_DOCUMENTATION_HUB.html#medes-demo/step-4-2,R1-G02; R1-G03; R1-G04,Not run,,,,,,,Not run,
MEDES-04-03,R1-MEDES-04,MEDES,"Communicate, generate correspondence and follow delivery",Module journey,P0,"the approved letter and verify its current recipient, destination, complete PDF and review outcome.","Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | the approved letter and verify its current recipient, destination, complete PDF and review outcome. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Select a connection and submit once
1. Open the approved letter and verify its current recipient, destination, complete PDF and review outcome.
2. Select Provider connection. The choices are limited to the letter’s channel and show whether setup is required, disabled, Test mode or Live.
3. For a configured enabled live connection choose Queue delivery. For a test/unconfigured connection, Save pending delivery records the request without claiming live dispatch.
4. Open Delivery history and note the current status and provider reference.
5. Use Refresh to inspect later changes. Background provider checks are designed for five-minute intervals; repeated manual refresh does not make the provider deliver faster.
6. If submission confirmation fails, use Retry same delivery request. Check the existing record before creating any new outbound request.
Delivery status dictionary
State | Meaning | Action / owner | 
WAITING_CONFIGURATION | A connection lacks required setup or is disabled. | Communications administrator configures it; operator then releases the approved pending request. | 
TEST_ONLY | The selected connection is in test mode. | No external delivery has occurred. Use an approved live setup for actual dispatch. | 
QUEUED | A delivery request is waiting for processing. | Monitor history; cancellation may be available before external submission. | 
LEASED | The worker has claimed the delivery request. | Wait for the recorded processing result; do not create another send. | 
SUBMITTING | An external submission is in progress. | Inspect the eventual provider result. | 
ACCEPTED | The provider accepted the request. | Await confirmed delivery; accepted is not delivered. | 
DELIVERED | The provider confirmed delivery. | Inspect the receipt/history; use it as delivery evidence where appropriate. | 
FAILED | Rendering or delivery needs attention. | Read the specific error. Correct the source/configuration before another authorized attempt. | 
UNKNOWN | The provider’s response was not confirmed. | Reconcile with the provider’s actual record before sending again. Escalate to delivery operations. | 
NEEDS_REVIEW | Connection settings changed after queuing. | Review the connection and release only after the required checks. | 
CANCELLED | The pending request was cancelled. | Inspect the recorded cancellation; no completion should be inferred. | 
Release and cancel pending delivery
When provider setup has been completed and the exact letter remains approved, use Release after provider setup if offered. The current access and provider configuration are checked again. Use Cancel pending delivery only while the application permits it. It is not a recall of an already-submitted fax, email or physical letter.
For UNKNOWN, do not work around the warning by generating a duplicate letter. Give delivery operations the correspondence reference, provider reference if present, channel and recorded time. They must determine whether the first submission exists at the provider.
Where to monitor each channel
Work area | Use | 
Transmission log / Transmission details | Inspect the recorded status and history of the exact correspondence delivery. | 
Fax correspondence / Fax recipient status | Follow fax work and recipient destinations. | 
Print and mail tracking | Inspect the print/mail request and the latest provider-confirmed status. | 
On-demand correspondence | Locate generated letters and email correspondence across permitted channels. | 
Pending correspondence | Identify outstanding items needing preparation, review, provider setup or confirmation. | 
Pulse Delivery operations | Authorized operator recovery and provider/job investigation. The MEDES case and content permissions still apply. | 
Provider availability in this edition: The implementation includes adapter support for RingCentral/Phaxio fax, Lob print/mail, and Graph/SendGrid/SMTP email. Six local test connections were prepared without live credentials or activation. An available adapter is not an active provider account. Final external delivery remains subject to real configuration and acceptance.
Check before continuing: The latest attempt has an attributable provider state or an explicit configuration blocker; generation is not counted as delivery.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The latest attempt has an attributable provider state or an explicit configuration blocker; generation is not counted as delivery.,documentation/KERNEL_DOCUMENTATION_HUB.html#medes-demo/step-4-3,R1-G02; R1-G03; R1-G04,Not run,,,,,,,Not run,
MEDES-04-04,R1-MEDES-04,MEDES,"Communicate, generate correspondence and follow delivery",Module journey,P0,"the original correspondence and choose Reply to correspondence, or open Reply – On-demand Correspondence and select the original item.","Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | the original correspondence and choose Reply to correspondence, or open Reply – On-demand Correspondence and select the original item. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
Prepare a reply linked to original correspondence
1. Open the original correspondence and choose Reply to correspondence, or open Reply – On-demand Correspondence and select the original item.
2. Verify Original correspondence and the associated case/member. Enter Reply subject and Reply message.
3. Choose one or more Delivery channels: Secure portal, Fax, or Print and mail.
4. For Secure portal, Add recipient from the eligible directory and optionally Request a read receipt.
5. For Fax or Print and mail, choose a Published template and enter Recipient name and the required fax/postal destination. Select case-document attachments if needed.
6. Choose Prepare and send reply. If confirmation is interrupted, use Retry same reply.
7. Review Response by channel. Open each result to continue its own next step. The portal branch records a secure message; fax/print-mail branches create correspondence requiring PDF preparation and independent review before external delivery.
Reply subject supports up to 200 characters and Reply message up to 4,000 characters. The published letter is followed by the reply text. Check the whole PDF before approval. This particular reply screen offers portal/fax/print-mail; direct email correspondence is prepared in the letter-generation workflow.
Screen 8Correspondence reply channel choices and destination fields. Test values are illustrative only.Historical application recorded test · illustrative records · completion/reply-compose.png · click to enlarge. Appearance may differ in the installed release.
Start a customer-support activity
1. Open the exchange case and choose Respond to customer, or find the case from that workspace.
2. Confirm that the member reference is current. Enter Activity note and choose Start support activity.
3. Choose the permitted response route: Secure message, Create fax, Prepare correspondence or Upload additional files.
4. Complete the selected work. Return to the support activity using the offered return navigation.
5. Choose Link a response, select the appropriate recorded response type and enter a note explaining its relevance.
6. Link the actual case-bound message, correspondence or document intake record. Inspect its readiness in Recorded responses.
Close or reopen support work
1. For Closure outcome Responded — confirm recorded evidence, ensure the linked evidence has reached the required confirmed state. A pending fax or unprocessed upload does not establish a completed response.
2. If no response is needed, an authorized user may select No further action needed and record the explanation.
3. Enter the final Activity note and choose Close support activity.
4. Verify the recorded closed outcome. If further follow-up is required later, choose Reopen activity with a new note.
5. Inspect the preserved activity and response history. Reopening a support activity does not rewrite a prior case or eligibility decision.
Follow-up versus decision: Customer-support activity tracks the response to a customer. It does not approve eligibility, complete a document review or override the external delivery state. Those outcomes remain in their respective workflows.
Check before continuing: The reply or follow-up is linked to its original case/item and the required response evidence is retained.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The reply or follow-up is linked to its original case/item and the required response evidence is retained.,documentation/KERNEL_DOCUMENTATION_HUB.html#medes-demo/step-4-4,R1-G02; R1-G03; R1-G04,Not run,,,,,,,Not run,
MEDES-05-01,R1-MEDES-05,MEDES,Monitor work and administer configuration,Module journey,P0,the configured MEDES landing workspace,"Use a fictional member/case under approved tenant/domain access, eligible case operator and independent reviewer identities, admitted test documents and published Pulse content. Confirm current recipient/provider configuration and worker readiness for the exact channel being verified. Prepare a safe completed record for features whose live provider prerequisite remains parked.","Before you act | Required context | 
Screen / entry | the configured MEDES landing workspace | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Use a fictional member/case under approved tenant/domain access, eligible case operator and independent reviewer identities, admitted test documents and published Pulse content. Confirm current recipient/provider configuration and worker readiness for the exact channel being verified. Prepare a safe completed record for features whose live provider prerequisite remains parked. | 
Steps and field guidance
Start from your role workspace
1. Open the configured MEDES landing workspace. State/support/reporting/compliance users have general-dashboard proposals; case workers have a case-workload dashboard; document reviewers have a reviewer dashboard. Some operational role proposals land directly in their work queue or correspondence list.
2. Confirm the displayed domain/profile and Dashboard role, where available.
3. Read the current report cards. A card can be an authorized total or explicitly labeled Records in this preview.
4. Choose Open report for the record list, or a Next actions link for operational work.
5. Choose All MEDES reports to browse the reports permitted by the role. The role selector does not assign new access.
Operational report catalog
Report | Purpose | Entry | 
My document uploads | Uploads created by you in the current tenant. Storage, security screening and business review are separate steps. | My uploads | 
My document review work | Open reviews assigned to you. Open Document reviews to inspect the document and record your decision. | Document reviews | 
My review requests | Reviews you requested in the current tenant, including their recorded outcomes. | Document reviews | 
My documents to correct | Your returned reviews awaiting a replacement upload. Reviews already linked to a replacement are excluded. | Document reviews | 
My case work | Case work you requested, reviewed or currently own in this workspace. | Case work queue | 
Available case reviews | Unclaimed case reviews available to your current profile. | Case work queue | 
Available eligibility reviews | Independent eligibility reviews available to your current profile. Your own case reviews are excluded. | Case work queue | 
Team case work | Supervisor view of case work within your current member and tenant access. | Assignment management | 
Escalated case work | Escalations visible to your supervisor profile. Open the queue to inspect the reason and route the next step. | Assignment management | 
Outstanding correspondence | Correspondence without confirmed delivery, excluding cancelled requests. Provider acceptance does not confirm delivery. | Pending correspondence | 
Fax transmissions | Fax requests and their current provider status within your current case and member access. | Transmission log | 
Email correspondence | Email delivery requests. An accepted submission does not establish receipt by the destination mailbox. | On-demand correspondence | 
Print and mail tracking | Print and mail requests with the latest provider status. Only confirmed deliveries appear as delivered. | Print and mail tracking | 
Deliveries to reconcile | Uncertain provider submissions requiring review before another delivery is attempted. | Transmission details | 
Open and export operational report data
1. Open MEDES reports and use Find a report to search its name or purpose.
2. Open the report and check Updated time and the matching-record count.
3. Use the page controls to inspect additional records. Open source record where provided, or Open work area to use the owner workspace’s filters/actions.
4. Choose Refresh report for a new read of the current data.
5. When permitted, choose Export displayed page. This CSV contains the currently displayed page, not every matching record in the system.
Reviewer and case-workload statistics
Workspace | What the figures mean | 
Document reviewer dashboard / My review statistics | Current assigned, pending and overdue reviews; approved/returned/rejected outcomes within the selected 7-, 30- or 90-day period; on-time completions; average request-to-decision time; oldest pending request. | 
Case workload dashboard | Current authorized tasks by state, completed tasks in the period, high/urgent open work, overdue and due-soon tasks, and tasks without a recorded deadline. | 
Workload scope | My case work is personal. Authorized team work is offered only with the team permission. | 
Completed work by day | The chart and table use the same recorded completion dates in UTC. The current workload count and a period’s completion count measure different things. | 
Delivery and recipient analytics
1. Open Fax Transmission Summary, Recipient delivery analytics or Recipient correspondence analytics.
2. Set Period (Today, last 7, 30 or 90 days), Outcome and available Channel. Search by case, letter, recipient or transmission reference, then Apply filters.
3. Read Delivery outcomes: created, confirmed delivered, preparation/review, pending provider delivery, accepted awaiting confirmation, failed, unconfirmed and cancelled.
4. Inspect Daily activity and Recipients. Open a recipient to filter totals and records to that destination. The recipient table shows up to the 20 busiest destinations; narrow search for others.
5. Open a Matching correspondence record to resolve an exception in the source workspace.
6. Use Export daily summary if permitted. This exports the daily aggregate table, not all underlying correspondence records.
Confirmed delivery rate is based on confirmed delivery, not provider acceptance. Average queue-to-delivery time measures queueing through confirmation; it is not fax call duration. Daily counts use correspondence creation dates in UTC and include days with zero activity.
Find and export saved Vista outputs
1. Choose Find generated reports / Search Reports or the permitted Vista runs workspace.
2. Enter Report name or status and optional Run from (UTC) / Run through (UTC), then choose Search outputs.
3. Open a saved output and inspect its report name, published version, generated time and record count.
4. Read the Recorded output. This is the saved result of a recorded run, not a newly executed query.
5. If export is permitted, enter Export reason (8–1,000 characters) and choose Export CSV or Export Excel.
6. To create or change a report definition, use Published Vista templates or Report studio with the separate authoring/publication permissions.
The generated-output search follows current dataset access and can include outputs from other permitted modules. It is broader than the MEDES operational catalog. Do not assume an old saved report proves the current status of a task; open the live work area for that.
Check before continuing: The report uses the selected role/domain and filter scope. Its rows and totals can be traced to the corresponding authorized case or operational records.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The report uses the selected role/domain and filter scope. Its rows and totals can be traced to the corresponding authorized case or operational records.,documentation/KERNEL_DOCUMENTATION_HUB.html#medes-demo/step-5-1,R1-G02; R1-G03; R1-G04,Not run,,,,,,,Not run,
MEDES-05-02,R1-MEDES-05,MEDES,Monitor work and administer configuration,Module journey,P0,the bell in the application header and select the relevant MEDES notification action.,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | the bell in the application header and select the relevant MEDES notification action. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
A notification is an invitation to inspect a business record. Opening it, marking it read, or receiving an email does not approve or complete that record. The authoritative status and action remain in the destination workspace.
Act on a notification
1. Open the bell in the application header and select the relevant MEDES notification action.
2. Read the event and its reference. Use the action link rather than guessing which record to search for.
3. If sign-in is required, complete it with your own authorized account and select the correct profile.
4. At the destination, verify the record identity, current status and permitted next action. The record may have changed after the notification was generated.
5. Complete the actual business action in that screen, then return to the notification list and mark the notification read if needed.
Event | Email action / destination | Expected next step | 
Document submitted / review required | Open document review | Owner follows progress; assigned independent reviewer inspects the exact document and decides. | 
Review approved / rejected / changes requested | Open document review | Read the outcome; for returned evidence, create a replacement or corrected letter. | 
Secure documents requested | Upload requested documents | Named recipient signs in, uploads and selects Submit documents. | 
Documents submitted | Review submission | Receiving team checks screening and begins intake when ready. | 
Secure-upload accepted / returned / closed | View submission status | Read progress or the recorded reason. Request a new link where needed. | 
Case work updated / completed | Open case work | Inspect assignment, stage, task status and history. | 
Secure message available | Read secure message | Open the authorized conversation and respond as appropriate. | 
Correspondence status changed | View correspondence | Check preparation, review, provider status or confirmed delivery. | 
Email and access behavior
The prepared Pulse notification templates include action links to the particular work item. They require correct publication and notification routing. Links remain subject to recipient, session, role and record-access checks. The MEDES flows documented here do not promise a temporary token that bypasses sign-in or document grants. A forwarded email does not transfer access.
If an alert arrives without a useful link, report its event/reference and template to the Pulse administrator. If the link opens an unavailable record, check profile, assignment, expiry and current record access. If an event produces no email, first check the authoritative work record; the event may still have completed while notification delivery needs attention.
Desktop push: Visible desktop push and notification-click acceptance were explicitly deferred from the current completion scope. This guide covers the application bell and prepared email deep links; it does not claim desktop push has passed live acceptance.
Check before continuing: The notification opens the intended authorized item or its required sign-in path. The user performs the business action separately from marking the notification read.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The notification opens the intended authorized item or its required sign-in path. The user performs the business action separately from marking the notification read.,documentation/KERNEL_DOCUMENTATION_HUB.html#medes-demo/step-5-2,R1-G02; R1-G03; R1-G04,Not run,,,,,,,Not run,
MEDES-05-03,R1-MEDES-05,MEDES,Monitor work and administer configuration,Module journey,P0,MEDES → Administration → MEDES settings.,"Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision.","Before you act | Required context | 
Screen / entry | MEDES → Administration → MEDES settings. | 
Who acts | Authorized operator / eligible independent reviewer as specified below | 
You need | Complete the previous step in this route, or reopen its eligible saved record. Confirm the same scope and revision. | 
Steps and field guidance
MEDES settings links to the platform that owns each setting. This avoids maintaining a second set of users, policies or templates inside MEDES. A visible MEDES settings page does not automatically authorize changes in the destination platform.
Open the owner workspace
1. Open MEDES → Administration → MEDES settings.
2. Find the configuration area by name or description.
3. Choose an available owner link. If no links are shown for an area, the current profile lacks access to those settings.
4. Review the current effective configuration and submit changes through the owner’s normal approval workflow.
5. After independent approval/publication, return to MEDES and refresh the affected workspace. Verify the actual intended behavior with the appropriate operational profile.
Need | Owner and starting point | Verification in MEDES | 
Users / domains / profiles / roles | IAM User accounts, Domains, Profiles, Roles and Approval queue. | Correct user can select the intended profile and only the permitted screens/actions. | 
Page layout, fields or controls | Axis Experience versions / Screens and controls; IAM Role and menu access. | The intended screen/control is published and its action rules are correct. | 
Logo / theme | Tenant Engine Current branding / Propose branding. | The published tenant branding appears in the workspace. | 
Document classes / metadata | Custodia Document classes, Metadata templates and Extraction and indexing. | Approved class appears in upload; required metadata can be completed; admission and indexing progress. | 
Reviewer document access | Custodia approved purpose/content grants. | The independent reviewer can preview the exact version without extra download/print rights. | 
Workflow / assignment / deadline | Regulix published process, assignment policies, SLA/calendar settings; MEDES Assignment management. | Review starts, correct independent worker is eligible, and due times reflect the published policy. | 
Letters / notifications / delivery | Pulse Letter templates, Email templates, Channel setup, Notification rules and Delivery operations. | Published MEDES template can generate; event reaches the intended user; live delivery has a verified receipt. | 
Entitlement / environment | Tenant Engine Effective settings and Configuration changes; TCP Environment control / Module subscriptions. | MEDES is available only in the authorized tenant context. | 
Reports / datasets | Vista Published reports, Report studio and Data sources. | Role sees appropriate reports and the result remains subject to current dataset access. | 
Retention / export / audit | Custodia Document retention / Governed exports; IAM User audit / Session history. | Policy and audit evidence can be inspected by the intended role. | 
User administration uses the IAM pattern
MEDES user administration opens the shared IAM User accounts functionality. Create, activation, sign-in setup, domain/profile assignment and independent access approval remain IAM operations. MEDES does not create a parallel identity record. An account can be active while its requested profile access still awaits approval.
For a new staff or partner user, the administrator establishes the account, completes the applicable activation/sign-in setup, proposes the domain/profile access, and obtains the required independent approval. The user then signs in and selects that authorized profile. Check the effective assignment rather than assuming that creating the account enabled the module.
Status and scope reference
MEDES status reference explains upload, intake, document-review, case-work, delivery and secure-message states and offers permitted links to the relevant work area. Use it when a chip’s meaning is unclear. It is reference material; selecting a status does not perform a state transition.
MEDES scope reference preserves three source qualifications: a full external partner self-service UI was not established by the R1 mailbox/API notes; page-level fax quality scoring depends on gateway capability; automated legal-hold expiry requires compliance approval. The reference is not a release-date commitment or a switch that enables those features.
Check before continuing: The settings entry leads to the appropriate owning module and permitted configuration. Unavailable owner links remain an access/configuration issue rather than an implied completed setup.
Keep the record number and version, any preview/decision/output reference, and the observed result. If the expected result is missing, stop this route and use the recovery chapter; a visible button alone is not completion.",The settings entry leads to the appropriate owning module and permitted configuration. Unavailable owner links remain an access/configuration issue rather than an implied completed setup.,documentation/KERNEL_DOCUMENTATION_HUB.html#medes-demo/step-5-3,R1-G02; R1-G03; R1-G04,Not run,,,,,,,Not run,
MEDES-EX-01,R1-MEDES-06,MEDES,Exception / recovery,Exception / recovery,P0,Document uploaded but case incomplete,"Use a fictional member/case under approved tenant/domain access, eligible case operator and independent reviewer identities, admitted test documents and published Pulse content. Confirm current recipient/provider configuration and worker readiness for the exact channel being verified. Prepare a safe completed record for features whose live provider prerequisite remains parked.","1. Prepare a disposable record exhibiting this condition: Document uploaded but case incomplete.
2. Check admission, classification and business review.
3. Reopen the affected record and its history; verify: Technical capture does not satisfy all case requirements.
4. Record actual outcome and supporting record/version or denial evidence.",Technical capture does not satisfy all case requirements.,documentation/KERNEL_DOCUMENTATION_HUB.html#medes-manual/decision-guide,R1-G02; R1-G03; R1-G04,Not run,,,,,,,Not run,
MEDES-EX-02,R1-MEDES-06,MEDES,Exception / recovery,Exception / recovery,P0,Published template available but release blocked,"Use a fictional member/case under approved tenant/domain access, eligible case operator and independent reviewer identities, admitted test documents and published Pulse content. Confirm current recipient/provider configuration and worker readiness for the exact channel being verified. Prepare a safe completed record for features whose live provider prerequisite remains parked.","1. Prepare a disposable record exhibiting this condition: Published template available but release blocked.
2. Inspect generated-item review, recipient, attachment and provider eligibility.
3. Reopen the affected record and its history; verify: Do not bypass case review because the template was approved.
4. Record actual outcome and supporting record/version or denial evidence.",Do not bypass case review because the template was approved.,documentation/KERNEL_DOCUMENTATION_HUB.html#medes-manual/decision-guide,R1-G02; R1-G03; R1-G04,Not run,,,,,,,Not run,
MEDES-EX-03,R1-MEDES-06,MEDES,Exception / recovery,Exception / recovery,P0,Fax/print-mail remains pending,"Use a fictional member/case under approved tenant/domain access, eligible case operator and independent reviewer identities, admitted test documents and published Pulse content. Confirm current recipient/provider configuration and worker readiness for the exact channel being verified. Prepare a safe completed record for features whose live provider prerequisite remains parked.","1. Prepare a disposable record exhibiting this condition: Fax/print-mail remains pending.
2. Check live provider activation/credential reference.
3. Reopen the affected record and its history; verify: Keep the parked dependency explicit; do not manufacture a delivery confirmation.
4. Record actual outcome and supporting record/version or denial evidence.",Keep the parked dependency explicit; do not manufacture a delivery confirmation.,documentation/KERNEL_DOCUMENTATION_HUB.html#medes-manual/decision-guide,R1-G02; R1-G03; R1-G04,Not run,,,,,,,Not run,
MEDES-EX-04,R1-MEDES-06,MEDES,Exception / recovery,Exception / recovery,P0,Provider outcome uncertain,"Use a fictional member/case under approved tenant/domain access, eligible case operator and independent reviewer identities, admitted test documents and published Pulse content. Confirm current recipient/provider configuration and worker readiness for the exact channel being verified. Prepare a safe completed record for features whose live provider prerequisite remains parked.","1. Prepare a disposable record exhibiting this condition: Provider outcome uncertain.
2. Inspect attempt/provider reference and tracking result.
3. Reopen the affected record and its history; verify: Avoid automatic resend of an operation that may already have occurred.
4. Record actual outcome and supporting record/version or denial evidence.",Avoid automatic resend of an operation that may already have occurred.,documentation/KERNEL_DOCUMENTATION_HUB.html#medes-manual/decision-guide,R1-G02; R1-G03; R1-G04,Not run,,,,,,,Not run,
MEDES-EX-05,R1-MEDES-06,MEDES,Exception / recovery,Exception / recovery,P0,Letter returned for correction,"Use a fictional member/case under approved tenant/domain access, eligible case operator and independent reviewer identities, admitted test documents and published Pulse content. Confirm current recipient/provider configuration and worker readiness for the exact channel being verified. Prepare a safe completed record for features whose live provider prerequisite remains parked.","1. Prepare a disposable record exhibiting this condition: Letter returned for correction.
2. Create the linked corrected draft/output and repeat affected review.
3. Reopen the affected record and its history; verify: Preserve the original PDF and decision history.
4. Record actual outcome and supporting record/version or denial evidence.",Preserve the original PDF and decision history.,documentation/KERNEL_DOCUMENTATION_HUB.html#medes-manual/decision-guide,R1-G02; R1-G03; R1-G04,Not run,,,,,,,Not run,
MEDES-EX-06,R1-MEDES-06,MEDES,Exception / recovery,Exception / recovery,P0,Support activity cannot close as responded,"Use a fictional member/case under approved tenant/domain access, eligible case operator and independent reviewer identities, admitted test documents and published Pulse content. Confirm current recipient/provider configuration and worker readiness for the exact channel being verified. Prepare a safe completed record for features whose live provider prerequisite remains parked.","1. Prepare a disposable record exhibiting this condition: Support activity cannot close as responded.
2. Check required confirmed response evidence.
3. Reopen the affected record and its history; verify: Outbound communication alone is not a customer response.
4. Record actual outcome and supporting record/version or denial evidence.",Outbound communication alone is not a customer response.,documentation/KERNEL_DOCUMENTATION_HUB.html#medes-manual/decision-guide,R1-G02; R1-G03; R1-G04,Not run,,,,,,,Not run,
R1-X01,REQ-R1-X01,Core → Tenant → TCP,Cross-module,Cross-module,P0,Core → Tenant → TCP owner screens,"Authorized organization steward, onboarding maker, reviewers and operator; synthetic organization.",1. Create or select one Core organization and record its ID. 2. Create/resume tenant request bound to that ID. 3. Complete independent registration/evidence/configuration/commercial steps. 4. Register the environment and run owner checks. 5. Request permitted activation and inspect signed truth.,"Organization, request, tenant, environment and truth references remain traceable; activation waits for every current required owner decision.",documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,R1-G14,Not run,,,,,,,Not run,
R1-X02,REQ-R1-X02,Tenant / TCP → IAM,Cross-module,Cross-module,P0,Tenant / TCP → IAM owner screens,An active test tenant with explicit module entitlement; IAM maker and independent checker.,1. Add domain/profile/role mappings for a narrow module. 2. Assign a test account. 3. Sign in and select the profile. 4. Compare module entitlement with user menus and controls. 5. Use an ungranted profile for the deny check.,Tenant entitlement and IAM user grants are both required; neither automatically creates the other.,documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,R1-G14,Not run,,,,,,,Not run,
R1-X03,REQ-R1-X03,IAM → Axis,Cross-module,Cross-module,P0,IAM → Axis owner screens,"Test screen/control, menu, permission, role/profile and distinct reviewer.",1. Review domain/profile/role/permission/menu chain. 2. Save and approve IAM-owned menu-screen and permission-control links. 3. Publish eligible Axis presentation. 4. Load the screen under allowed and denied profiles. 5. Check direct record URL/API through the supported test harness.,Axis supplies rendering; IAM supplies effective RBAC/ABAC decisions. Direct access cannot bypass a missing grant.,documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,R1-G13,Not run,,,,,,,Not run,
R1-X04,REQ-R1-X04,Custodia → Tenant evidence,Cross-module,Cross-module,P0,Custodia → Tenant evidence owner screens,Synthetic admitted document and a second quarantined/unfinished fixture.,1. Capture document and record version/hash. 2. Attach admitted version to tenant identity evidence. 3. Submit for review. 4. Attempt to rely on the unfinished fixture. 5. Reopen the approved evidence from onboarding.,Reviewed evidence identifies an admitted custody version; an incomplete/quarantined upload cannot be treated as accepted proof.,documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,,Not run,,,,,,,Not run,
R1-X05,REQ-R1-X05,Source → Dataset → Vista report,Cross-module,Cross-module,P0,Source → Dataset → Vista report owner screens,Supported test HTTPS JSON source and secret reference; separate data/content reviewers.,"1. Define connection, test it and discover permitted fields. 2. Build dataset with approved tenant filter. 3. Preview current rows and independently review/publish dataset. 4. Create named report from blank canvas or template. 5. Save, preview, submit, independently review and publish.","Connection, dataset, report and preview receipts reference exact versions; dataset and report reviews are enforced independently.",documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,R1-G06,Not run,,,,,,,Not run,
R1-X06,REQ-R1-X06,Vista report → Dashboard → Scheduler,Cross-module,Cross-module,P0,Vista report → Dashboard → Scheduler owner screens,"Published report, dashboard-capable operation and eligible Run as identity.","1. Add published report to dashboard and preview. 2. Review/publish dashboard. 3. Author registered dashboard job, pin version and preview. 4. Independently approve/publish job. 5. Run once and inspect dashboard and run references.",A completed owner output is linked to the exact dashboard/job versions; accepted/pending execution is not reported as completed.,documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,R1-G14,Not run,,,,,,,Not run,
R1-X07,REQ-R1-X07,Dataset → Pulse email → Scheduler,Cross-module,Cross-module,P0,Dataset → Pulse email → Scheduler owner screens,"Published dataset, controlled record and published email operation; sending disabled for generation-only test.",1. Build named email template with row binding and responsive layout. 2. Save and preview current record. 3. Independently review/publish. 4. Create/preview/review/publish email-generation job. 5. Run and inspect generated email and attempt audit.,Merge values match current authorized record and pinned template version. Generation alone creates no claim of transport or inbox delivery.,documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,R1-G06,Not run,,,,,,,Not run,
R1-X08,REQ-R1-X08,Dataset → Pulse letter → Custodia,Cross-module,Cross-module,P0,Dataset → Pulse letter → Custodia owner screens,Long synthetic related-record dataset; published letter; approved storage/custody integration.,"1. Add repeat section, page break, headers/footers. 2. Save and preview multi-page current output. 3. Review/publish and run registered generation. 4. Inspect owner output and custody handoff when configured. 5. Compare page count, content, version/hash.",Output is complete and traceable; no clipped rows or mixed versions. Custody receipt is separately recorded when the handoff is configured.,documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,R1-G06,Not run,,,,,,,Not run,
R1-X09,REQ-R1-X09,MEDES → Custodia → Regulix,Cross-module,Cross-module,P0,MEDES → Custodia → Regulix owner screens,"Approved MEDES profile and case, reviewer, admitted synthetic evidence and published workflow.",1. Open member/case. 2. Upload and classify evidence. 3. Review/split/index as required. 4. Start/route the configured case work. 5. Complete eligible independent review and reopen case/evidence/task history.,"Case, document/version, task and decision link correctly; denial or return preserves evidence and history.",documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,R1-G02; R1-G03,Not run,,,,,,,Not run,
R1-X10,REQ-R1-X10,MEDES → Pulse → Provider → Response,Cross-module,Cross-module,P0,MEDES → Pulse → Provider → Response owner screens,Approved MEDES correspondence configuration and authorized test recipient; live transport if delivery is in scope.,1. Select published content for the case. 2. Review generated letter/recipient/channel. 3. Submit authorized dispatch. 4. Inspect provider acceptance and later delivery separately. 5. Record customer response and resulting case work.,"Generated, accepted and delivered states remain distinct; response links to correspondence/case. Parked fax/mail transport remains blocked rather than passed.",documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,R1-G02; R1-G03; R1-G04,Not run,,,,,,,Not run,
R1-X11,REQ-R1-X11,Nexora → Review → Learning outcome,Cross-module,Cross-module,P1,Nexora → Review → Learning outcome owner screens,"Published learning content, assigned learner, independent author reviewer and configured bounded certificate flow.",1. Author/review/publish content. 2. Assign it to learner. 3. Complete lesson and assessment. 4. Inspect attempt/outcome and eligible certificate. 5. Open corresponding authorized report/evidence.,"Publication, enrollment and completion are separate records; viewing alone cannot confer a passing outcome.",documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,R1-G10,Not run,,,,,,,Not run,
R1-X12,REQ-R1-X12,Scheduler source refresh → Vista,Cross-module,Cross-module,P1,Scheduler source refresh → Vista owner screens,Published registered source-refresh job and dependent report job with compatible execution context.,1. Create static success dependency batch. 2. Preview/review/publish applicable definitions. 3. Start bounded batch. 4. Observe refresh completion before report dispatch. 5. Inspect each run/output and checkpoint.,"Dependency uses confirmed success, retains separate output references and does not imply automatic output piping.",documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,,Not run,,,,,,,Not run,
R1-X13,REQ-R1-X13,Scheduler failure / resume,Recovery,Recovery,P0,Scheduler failure / resume owner screens,Disposable two-job static batch; controlled failure fixture; no shared worker shutdown.,1. Fail predecessor safely. 2. Confirm dependent work does not start. 3. Correct prerequisite through owner flow. 4. Use permitted rerun/resume. 5. Compare original failed run and new attempt/checkpoint.,Failure history is immutable; recovery does not duplicate completed jobs or invent record-level checkpoints.,documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,,Not run,,,,,,,Not run,
R1-X14,REQ-R1-X14,Scheduler calendar / backfill,Recovery,Recovery,P1,Scheduler calendar / backfill owner screens,Approved timezone/calendar and stopped disposable schedule with small missed window.,1. Preview once/interval/cron occurrences. 2. Check excluded holiday and DST policy. 3. Request missing-only bounded backfill. 4. Inspect occurrence/run deduplication. 5. Re-submit equivalent request.,"No duplicate occurrence; configured bounds enforced. Backfill uses current authorized data, not a historical data reconstruction.",documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,,Not run,,,,,,,Not run,
R1-X15,REQ-R1-X15,Cross-owner audit trail,Audit,Audit,P0,Cross-owner audit trail owner screens,"One completed synthetic cross-module transaction from X05, X08 or X09.","1. Start with originating record. 2. Follow proposal/version, decision, output and run references. 3. Record actors, context, timestamps and correlation IDs. 4. Compare viewer and operator visibility.",Ownership and lineage are explainable without raw credentials; viewer access remains scoped.,documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,,Not run,,,,,,,Not run,
R1-S01,REQ-R1-S01,IAM,Security,Security,P0,IAM owner screens,Same account assigned maker and checker profiles; separate authorized checker also available.,1. Submit a proposal as maker. 2. Switch the same account to checker. 3. Attempt approval. 4. Ask the distinct eligible identity to inspect and decide.,Profile switching does not create independence; same-person approval remains denied and true independent review succeeds where eligible.,documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,,Not run,,,,,,,Not run,
R1-S02,REQ-R1-S02,IAM / Axis,Security,Security,P0,IAM / Axis owner screens,Test profile with no menu/screen grant and known record URL.,1. Confirm menu is absent. 2. Open its direct route. 3. Attempt registered read and mutation through an approved API test method. 4. Review response and audit.,UI and server deny unauthorized access; hidden navigation is not the sole protection.,documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,,Not run,,,,,,,Not run,
R1-S03,REQ-R1-S03,All data owners,Security,Security,P0,All data owners owner screens,Two isolated test tenants/domains and distinct fixtures.,1. Read allowed record. 2. Switch to other authorized context. 3. Reuse old record URL and submitted identifier. 4. Attempt list/filter/export lookup.,No cross-tenant/domain data leakage or update; current server context controls access.,documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,,Not run,,,,,,,Not run,
R1-S04,REQ-R1-S04,IAM / Axis,Security,Security,P0,IAM / Axis owner screens,Profile with screen read but no sensitive-field or execution permission.,1. Inspect screen and protected controls. 2. Attempt forbidden action with direct request. 3. Inspect exported and previewed values.,Field/action policy is enforced at data/execution boundary as well as rendering.,documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,,Not run,,,,,,,Not run,
R1-S05,REQ-R1-S05,Dynamic navigation,Security,Security,P0,Dynamic navigation owner screens,Governed temporary role/menu permission assignment.,1. Observe menu under selected profile. 2. Revoke temporary grant with required review. 3. Refresh authorized context. 4. Attempt cached link and API.,Revoked access ceases to work after the supported refresh/expiry boundary; no static menu grants authority.,documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,,Not run,,,,,,,Not run,
R1-S06,REQ-R1-S06,Scheduler,Security,Security,P0,Scheduler owner screens,Queued disposable job using service identity and dataset grant.,1. Queue job. 2. Revoke its execution/data grant through supported governance before dispatch. 3. Observe worker outcome. 4. Inspect output/attempt audit.,Dispatch fails authorization and creates no owner output; original failure is retained.,documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,,Not run,,,,,,,Not run,
R1-S07,REQ-R1-S07,Sources / previews,Security,Security,P0,Sources / previews owner screens,Supported connection using private credential reference and restricted fields.,"1. Inspect connection fields and browser responses. 2. Test discovery and preview. 3. Inspect reports, exports and audit views for secret exposure.","Only permitted data is returned; credentials are referenced, never exposed as raw secrets in client output.",documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,,Not run,,,,,,,Not run,
R1-S08,REQ-R1-S08,Version governance,Security,Security,P0,Version governance owner screens,Draft/published artifact with reviewed exact version.,1. Preview saved version. 2. Change content or binding. 3. Attempt approval/publication using stale receipt/revision. 4. Save and repeat current preview/review.,Stale/tampered content cannot inherit approval; successor requires the applicable current review.,documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,,Not run,,,,,,,Not run,
R1-S09,REQ-R1-S09,Sessions / notifications,Security,Security,P1,Sessions / notifications owner screens,Disposable account session and authorized notification link.,1. Open link while signed out and authenticate. 2. Confirm record return. 3. Repeat after permission revocation or link expiry. 4. Inspect target actions.,Authentication return preserves context; the link does not confer access or approve work. Expired/denied access is handled clearly.,documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,,Not run,,,,,,,Not run,
R1-S10,REQ-R1-S10,Account forms,Security / usability,Security / usability,P1,Account forms owner screens,Disposable registration/login forms and configured expiry interval.,1. Leave form idle past its challenge lifetime. 2. Submit once. 3. Follow refresh/retry path. 4. Use Cancel/Back from credential replacement.,Stale challenge is explained and recoverable; secure verification stays enforced and the user is not trapped.,documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,,Not run,,,,,,,Not run,
R1-L01,REQ-R1-L01,Generic lifecycle,Lifecycle,Lifecycle,P0,Generic lifecycle owner screens,Disposable eligible master with active flag and lifecycle authorization.,1. Create without explicit active input where allowed. 2. Read saved availability. 3. Create explicit inactive value where supported. 4. Edit ordinary fields on inactive record.,New default follows contract; explicit false is preserved; ordinary editing never silently reactivates.,documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,,Not run,,,,,,,Not run,
R1-L02,REQ-R1-L02,Generic lifecycle,Lifecycle,Lifecycle,P0,Generic lifecycle owner screens,Inactive test record referenced by historical work.,1. Deactivate through governed action. 2. Search active and inactive views. 3. Try creating a new dependent record. 4. Open historical dependent work. 5. Use authorized restore if offered.,"New selection honors availability; historical lineage remains. Restore is explicit and policy-controlled, not a hard delete.",documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,,Not run,,,,,,,Not run,
R1-L03,REQ-R1-L03,Concurrency / retries,Recovery,Recovery,P0,Concurrency / retries owner screens,Two sessions on one disposable draft; controlled lost response.,"1. Open same revision in both sessions. 2. Save in first. 3. Save stale second revision. 4. On uncertain create/run result, read receipt before retry. 5. Reuse idempotency contract where supported.",Stale update conflicts safely and uncertain retry does not duplicate business objects or execution.,documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,,Not run,,,,,,,Not run,
R1-U01,REQ-R1-U01,Shared UI,Presentation,Presentation,P1,Shared UI owner screens,Agreed screen inventory and both Classic/Qbox themes.,"1. Apply the per-screen checklist to assigned routes. 2. Check standard heading, Back first, grid toolbar and responsive layout. 3. Inspect real font/icon resources. 4. Navigate between screens with network tools.",Consistent readable layouts; internal SPA navigation retains shell; intentional auth/external transitions are distinguished.,documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,,Not run,,,,,,,Not run,
R1-U02,REQ-R1-U02,Originating grid approvals,Presentation / security,Presentation / security,P0,Originating grid approvals owner screens,"Pending synthetic record and maker, eligible checker, denied reader profiles.",1. Locate proposal on owning screen grid. 2. Compare row actions across profiles. 3. Open preview/comparison. 4. Decide exact current version. 5. Reopen completed row.,Review stays linked to originating record; eligibility/current state govern actions on UI and API; completed work cannot be approved again.,documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,,Not run,,,,,,,Not run,
R1-U03,REQ-R1-U03,Source-to-Studio navigation,Usability,Usability,P1,Source-to-Studio navigation owner screens,Authorized source/dataset author and blank report/template/dashboard.,1. Define/pick sources. 2. Build/pick related datasets. 3. Enter name/basic details. 4. Enter Studio with correct area selected. 5. Save/reopen and navigate back.,Selected source/dataset/details persist; blank initial canvas and optional template choice are clear and recoverable.,documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,,Not run,,,,,,,Not run,
R1-U04,REQ-R1-U04,Rendered output,Output,Output,P0,Rendered output owner screens,Long multi-record report and letter; email mobile/desktop variants.,"1. Save version and inspect current-data preview. 2. Publish and execute same pinned version. 3. Compare text, totals, breaks, headers, repeated rows and fonts. 4. Inspect email at narrow/wide width.","No lost/clipped rows, wrong totals or version mismatch; pagination and responsive output fit supported target.",documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,,Not run,,,,,,,Not run,
R1-O01,REQ-R1-O01,Release / operations,Operational,Operational,P0,Release / operations owner screens,Approved controlled UAT environment; release owner and baseline record.,1. Record UI/API/worker and configuration versions. 2. Check health and expected unauthorized boundaries. 3. Verify worker heartbeat and eligible queue. 4. Run one harmless registered job and inspect audit.,Installed components match frozen baseline; readiness and completed owner output are evidenced independently.,documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,R1-G14,Not run,,,,,,,Not run,
R1-O02,REQ-R1-O02,Recovery / rollback,Operational,Operational,P0,Recovery / rollback owner screens,"Isolated rehearsal environment, verified backup and change-specific rollback plan.",1. Restore backup in isolation. 2. Apply/replay migration/configuration candidate. 3. Exercise owner smoke cases. 4. Rehearse rollback and readback. 5. Record data/recovery interval and unresolved side effects.,Recovery evidence identifies exact baseline and limits; external effects are reconciled rather than assumed reversed.,documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,R1-G15,Not run,,,,,,,Not run,
R1-O03,REQ-R1-O03,Performance / accessibility,Nonfunctional,Nonfunctional,P1,Performance / accessibility owner screens,"Agreed load, latency and browser/device/accessibility targets recorded before run.","1. Run representative search, dataset preview, large grid and report/letter cases at agreed volumes. 2. Record percentiles/error rates. 3. Verify keyboard/focus, labels, zoom and narrow layout. 4. Compare to agreed targets.",Results meet agreed thresholds or are logged as defects; this package supplies no invented SLA or blanket accessibility certification.,documentation/KERNEL_DOCUMENTATION_HUB.html#kernel-crosswalk,R1-G15,Not run,,,,,,,Not run,