Records
Records
Records are information DX Complete keeps so decisions, work, service issues, and measurements can be followed over time.
Records are grouped by how they are usually used. Some records, especially Task and Decision, can appear in any phase when they help keep the work clear.
Shared records also have a short reference such as RQM-0001, so people can refer to them without reading the full system ID.
Choosing the right record
Use the clearest dedicated record first. Journal is for useful context only when the information has no better home.
Use these when the information says what should be true, what success looks like, or what must be made buildable.
Use Decision when alternatives were considered and a choice should remain visible.
Use Task when an internal role needs to do or coordinate work.
Use Change for a discrete alteration to the running service, with plan, execution, rollback, risk, and event history.
Use Support Request for a user-facing question, request, or issue that needs shared follow-up.
Use Risk when something uncertain could affect value, delivery, service, or compliance.
Use the Operational Registry for what exists, where it lives, and which secret locations matter.
Use Maintenance Schedule for recurring service hygiene, such as scheduled checks, reviews, rotations, or maintenance duties.
Use Value Realization when actual before-and-after value can be compared.
Use a ticket first when a user raises a question, report, request, correction, or follow-up with DX Complete.
Use Dev Log for internal context about what landed in the workspace repository.
Use Journal for relevant background, preference, observation, or context that does not fit a dedicated record.
The simplest test is: will another record depend on this, satisfy it, or use it as an input? If yes, choose a dedicated record. If a Journal note later becomes important to decisions or work, promote it to the right record.
Set the need
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 work is transformation, greenfield, limited disclosure, or mixed.
Whether the workspace is active, paused, closed, or being reviewed.
Other service spaces connected to this one.
StatementA person's own words before they are interpreted or translated.
The request, concern, idea, direction, objection, or observation as expressed.
Who or what the statement came from.
Where it came up and what was happening around it.
The expectation restated from this statement.
JournalShared workspace notes for useful context that has no dedicated record home.
Free-form context, preference, background, observation, or other relevant information.
Who added the entry and when it was added.
A short free-form label to help filter or scan entries.
A compact entry that points back to the notes it summarizes.
Older notes can leave the default view after they are summarized, while still remaining retrievable.
Entries can be linked when they inform a decision, risk, requirement, or other record.
Dev LogInternal code-history context for what has landed in the workspace repository.
The recorded commit reference, message, author, commit time, and branch.
Internal users can see Dev Log entries; End Users do not see this record.
A compact entry can summarize older commit ranges while keeping the original detail retrievable.
When a Change records the same commit reference, the relationship is shown from the matching code-history entry.
Each workspace treats one repository as its code-history source.
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 not decided yet, approved, not approved, or superseded.
The authority who approved the expectation when approval is needed.
Engineer input that should remain visible without blocking progress.
Highlights a review note without requiring an Owner response.
Prior wording kept when the expectation changes.
The original statement that led to this expectation.
The requirement meant to satisfy this expectation.
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.
Engineer input that should remain visible without blocking progress.
Highlights a review note without requiring an Owner response.
Prior wording kept when the requirement changes.
How important it is compared with other requirements.
Links to risks, decisions, costs, benefits, or tasks.
Decide whether to commit now or defer
EstimateAn itemized cost view for the scope being weighed.
The individual cost entries, each with amount, timing, period when recurring, and currency.
The requirements or expectations the Estimate covers.
Grouped cost totals that keep one-time, recurring, period, and currency separate.
Prior versions are kept when the Estimate changes.
BenefitsThe expected value for the scope being weighed.
The expected benefits, with amounts where they can be estimated and plain descriptions where they cannot.
The requirements or expectations the Benefits record covers.
Grouped totals for quantified benefits only.
Prior versions are kept when Benefits change.
Value RealizationMeasured before-and-after value for expectations, requirements, or commitments.
One or more measures with a baseline, unit, direction, and optional actual value.
The expectations, requirements, or commitments the measurement relates to.
Measured metrics show improvement, regression, no change, or an open measurement gap.
Prior versions are kept when metrics change.
CommitmentAn Owner record that moves requirements or expectations into Build.
What the Owner is committing to move forward.
The requirements or expectations included in the Commitment.
Concerns the Owner is moving forward despite.
The earlier Deferral this Commitment resolves.
DeferralAn Owner record for not committing yet, with conditions for a future Commitment.
Why the Owner is not committing yet.
What must be addressed before a future Commitment.
Notes and updates showing how the conditions changed over time.
Whether the Deferral is open, resolved, or abandoned.
RiskSomething uncertain that could affect value, delivery, service, compliance, or operations.
The uncertainty or exposure being tracked.
Identification, assessment, treatment, monitoring, closure, and reopening entries kept in order.
Whether the risk is open or closed, derived from the latest status entry.
The latest likelihood and impact assessment.
The latest response: accept, mitigate, transfer, or avoid.
Formal risk acceptance belongs to the Owner.
Act on the work
TaskInternal work orders with an entry history and a current status from the latest status entry.
The work to be done.
The practical explanation of the work.
The requirement the task supports, when the task implements a requirement.
Status changes kept in order. The latest status entry is the current status.
The role expected to act, such as Owner, Engineer, Tester, Operator, Support Agent, or End User.
The named person expected to act, when the work is assigned to a specific person.
Who assigned or requested the work.
A task can stay unassigned when responsibility is not settled yet.
Comments, notes, and status changes that preserve how the task moved over time.
ChangeA record for a specific alteration to the running service.
Whether the change is standard, normal, or emergency.
What is changing, why, scope, timing, and notice.
The ordered steps for carrying out the change.
How to reverse or recover if the change should not remain in use.
The expected risk, service impact, open concerns, and downstream impact: what else may be affected and what depends on what is changing.
Notice, veto, decision, result, recovery, notes, and revisions kept in order. Result and recovery events can include optional Git commit references.
Use Change for run-side service alteration, not ordinary build work.
IncidentA specific service-impacting or potentially service-impacting occurrence.
What happened or may be happening.
Detection, updates, severity changes, resolution, reopening, and notes kept in order.
Whether the Incident is open or resolved, derived from entries.
The latest recorded severity.
The operational items affected by the occurrence.
ProblemAn underlying or recurring cause evidenced by one or more Incidents.
The cause or pattern being investigated.
The Incidents that provide evidence for the Problem.
Identification, investigation, root cause, known error, resolution, reopening, and notes kept in order.
The latest Problem state derived from entries.
The latest recorded root cause.
Support RequestA support record for a user-facing question, request, or issue, visible to the filer and internal users.
The person, role, or channel that reported the experience.
The person who filed the request.
What the user reported, requested, asked, or experienced.
Raised, triage, update, escalation, resolution, reopening, and notes kept in order.
Replies are marked unread for the filer until the request is read.
The latest support state derived from entries.
An Incident linked when the support request becomes an operational occurrence.
End Users can submit, read, follow up on, reopen, and see unread replies for their own Support Requests.
Know what exists
EnvironmentA named operating context such as local, staging, or production.
The name people use for this operating context.
What the environment is for and how people should understand it.
Prior versions are kept when the Environment changes.
ComponentOne operational item that belongs to one Environment.
The operating context this Component belongs to.
A plain label such as app, database, storage, queue, service, or another useful term.
Where the Component lives, such as a URL, project, region, host, or route.
Non-secret names such as database name, account, project, region, or username.
Where relevant secrets are stored and what they are called. Do not put credential values here.
Useful operating context that belongs with this Component.
Prior versions are kept when the Component changes.
Maintenance ScheduleRecurring operational hygiene with cadence and due state.
What recurring operational duty this schedule represents.
How often the work should happen.
The first date used to calculate when the work is due.
Next due date and overdue state are derived from cadence and linked completed Changes or Tasks.
Prior versions are kept when the schedule changes.
The Operational Registry is inventory only. It does not monitor, diagnose, store secret values, keep event history, or replace operating procedures.
Decide and follow up
DecisionA recorded choice with ordered entries and links to the records that informed it.
The issue or choice being decided.
Choices kept in order. The latest decision entry is the current decision.
Arguments, facts, tradeoffs, or concerns that were visible at the time.
Other context that should remain with the decision.
The records that informed the choice.
What should happen because of the choice.
DX Complete TicketA ticket for a question, report, request, correction, or follow-up with DX Complete.
A short name for the ticket.
The original question, report, request, correction, or follow-up.
Later updates added without replacing what was first recorded.
Responses addressed back to the person who raised the ticket.
The submitter and internal users can see it; unrelated End Users cannot.
Open, resolved, or reopened status comes from status-bearing entries.
End Users use Support Requests for service support follow-up.
A requirement, task, risk, change, or decision can be created separately if follow-up is needed.
Tickets keep text entries; file or asset handling belongs elsewhere.
Kept inside records
These are normally captured in requirements, risks, decisions, review notes, or task details.
Checks and outcomes can be captured in task details, change history, decisions, or linked notes.
These are currently represented through Change events, risks, decisions, and supporting notes.
Operational signals can be handled through tickets, incidents, problems, risks, tasks, changes, decisions, or new requirements.
Actual cost or benefit observations can update estimates, benefits, risks, decisions, or future work.