Records
Records
Records are information DX Complete keeps so decisions, work, service issues, and measurements can be followed over time.
Records are grouped by where they usually appear in the flow. Open a record to see recommended fields and which ones are optional.
Set the context
WorkspaceThe container for one service and the work connected to it.
The name people use for this service space.
What service or area the workspace contains.
Whether the workspace is active, paused, closed, or being reviewed.
Other service spaces connected to this one.
Service CharterA short statement of the service name, description, problem, and goal.
The name people use for the service or effort.
A short explanation of what the service is about.
The problem or need being addressed.
The outcome the work is meant to support.
InitiativeThe request or opportunity being considered.
A clear name for the request or opportunity.
What is being considered and why it matters.
Where the request came from.
Whether the work is transformation, greenfield, limited disclosure, or mixed.
Whether the initiative is active, paused, stopped, or committed.
VoiceA person's own words before they are interpreted or translated.
The request, concern, idea, approval, objection, or observation as expressed.
Who or what the voice came from.
Where it came up and what was happening around it.
The expectation restated from this voice.
ExpectationThe result a person or group expects, including how success will be recognized.
The restated result and success condition in plain language.
Whether it is confirmed, corrected, open, or moving forward with accepted risk.
The original voice that led to this expectation.
The requirement meant to satisfy this expectation.
DecisionThe recorded choice, who made it, the reason given, and the points considered.
The issue or choice being decided.
The choice that was made.
The role or person accountable for the choice.
Why the accountable role or person made the choice.
Arguments, facts, tradeoffs, or concerns that were visible at the time.
Objections or unresolved issues that remain after the choice.
When the choice was made.
What should happen because of the choice.
Understand the need
Intake ItemA private place to keep loose input at the front door before triage.
A short name for the item.
The original report, request, observation, correction, feedback, or follow-up.
Later updates added without replacing what was first recorded.
Hide the item from the active list when it no longer needs attention.
A requirement, task, ticket, incident, risk, or decision can be created separately if follow-up is needed.
Intake keeps text entries; file or asset handling belongs elsewhere.
RequirementA commitment to make something true in a buildable and checkable way.
What the team is committing to make true.
How people will know the requirement is satisfied.
The expectation this requirement is meant to satisfy.
Extra behavior, edge cases, or check notes needed to build or verify the requirement.
How important it is compared with other requirements.
Links to risks, decisions, costs, benefits, or tasks.
ConstraintsLimits that affect the work, such as time, access, policy, budget, or risk.
The limit that affects the work.
How the limit affects cost, delivery, scope, or operation.
The kind of limit, such as time, budget, access, policy, or risk.
Whether the limit is fixed or can be adjusted.
DependenciesPeople, systems, data, or decisions the work depends on.
What the work depends on.
Whether the dependency is open, ready, blocked, or resolved.
Who can help move it forward.
When the dependency matters.
UnknownsImportant questions that are not answered yet.
What is not known yet.
Why the missing answer matters.
Who is best placed to answer it.
When the answer is needed.
Decide whether to move forward
Business CaseThe reason for doing the work, including cost, value, risk, and confidence.
The reason to commit, pause, or stop.
The available cost baseline, estimate, or cost limits.
The expected value, when it can be described.
The main uncertainties affecting the case.
The proposed choice: commit, pause, or stop.
Cost BaselineWhat the current state costs now, when known.
Whether current cost data is known, partial, unavailable, or not applicable.
The current cost amount or range, when available.
The time period the cost covers.
Where the cost information came from.
Any assumptions used to interpret incomplete data.
Cost EstimateWhat the proposed future state is expected to cost.
The expected cost amount, range, or cost level.
What the estimate depends on.
How reliable the estimate is believed to be.
Major cost parts, such as build, run, support, or licensing.
Benefit EstimateThe expected value before work begins.
The value the work is expected to create.
The kind of value, such as revenue, savings, risk reduction, speed, quality, or experience.
How the benefit might be measured later.
What must be true for the benefit to occur.
RiskSomething uncertain that could affect value, delivery, service, or compliance.
The uncertainty or exposure.
What could happen if the risk occurs.
How likely the risk seems.
How the risk should be reduced, accepted, avoided, or watched.
The open confirmation or check that creates this risk.
Who is responsible for watching or handling it.
Create the change
TaskA piece of work needed to satisfy a requirement.
The work to be done.
The requirement the task supports.
Whether the task is open, active, blocked, review-ready, or done.
Who is doing or coordinating the work.
Change RequestA proposed change that needs review, approval, release, or deployment.
What is proposed to change.
Why the change is needed.
Whether the change is proposed, approved, held, or rejected.
The release where the change is expected to go live.
QA VerificationChecking that completed work meets the requirements and success criteria.
What was checked.
Whether the check passed, failed, or needs retest.
Notes or proof supporting the result.
Problems that need correction.
Product ValidationConfirming that the completed work achieves the intended outcome.
The intended outcome being reviewed.
Whether the result is accepted, rejected, or needs follow-up.
Who reviewed the outcome.
What should happen next if the outcome is not sufficient.
Put the change into use
ReleaseA set of changes prepared to be put into use.
The name or identifier for the release.
The changes included in the release.
Whether the release is ready, held, or needs more work.
Important release information for the team or users.
DeploymentPutting a release or change into use.
What was put into use.
Whether deployment succeeded, failed, was held, or was rolled back.
Where the change was put into use.
When it happened.
What to do, or what happened, if rollback is needed.
ControlA rule, check, or approval used to reduce risk.
The check, rule, or approval being used.
The risk or concern the control addresses.
What should be kept to show the control happened.
Who is responsible for the control.
EvidenceA record that supports a decision, check, release, or measurement.
What is being kept.
The decision, check, release, deployment, or measurement it supports.
Where the evidence can be found.
When the evidence was captured.
Run and support
Support TicketA user request, question, or issue report.
What the user needs help with.
How the user is affected.
Whether the ticket is open, waiting, resolved, or escalated.
How the request or issue was handled.
IncidentAn event that affects, or may affect, the service and needs a response.
What is affected or could be affected.
How serious the incident is.
Whether the incident is active, monitoring, resolved, or closed.
Who is coordinating the response.
How service was restored or protected.
ProblemAn underlying or repeated issue that may need deeper improvement work.
The repeated or underlying issue.
Whether the problem is open, under review, being improved, or closed.
Incidents or tickets that point to the problem.
What might reduce or remove the problem.
FeedbackA signal from a user, support interaction, service issue, or observed result.
The signal, comment, request, or observation.
Where the feedback came from.
Why the feedback matters.
Whether it should become support, improvement, requirement, or no action.
Learn from results
Actual CostThe cost measured after launch, when the data is available.
Whether actual cost is measured, partial, unavailable, or not yet ready.
The measured cost amount or range.
The time period the cost covers.
Where the cost information came from.
Benefit MeasurementThe value measured after launch, when the data is available.
Whether benefit is measured, partial, unavailable, or not yet ready.
The observed benefit or outcome.
The time period being measured.
Where the benefit information came from.
Estimate RefinementUsing real results to improve future cost and benefit estimates.
What was learned from the actual result.
The cost or benefit assumption that should change.
What supports the lesson.
How future estimates should be adjusted.