Operating guide
How roles use DX Complete
DX Complete is easiest to use when each person knows which records belong to their part of the work.
This guide shows the normal record choices by role. It is not meant to make every activity heavier. Use the smallest record that keeps the work understandable.
Direction, value, and authority
The Owner sets direction, weighs value against cost and risk, records Commitment or Deferral, validates outcomes, and formally accepts risk when the project should own it.
Statement, Expectation, Benefits, Value Realization, Commitment, Deferral, Decision, and Risk.
Do not turn every comment into a requirement. Do not use approval language for End User feedback.
Build from requirements
The Engineer turns committed requirements into tasks and working changes. Coding-capable tools such as Codex may assist the Engineer, but they are not separate DX Complete roles.
Use Requirement to Task for normal internal build work.
Use Decision for meaningful design choices or tradeoffs.
Use Risk when uncertainty could affect value, delivery, service, or compliance.
Use Change only when the work becomes a discrete alteration to the running service.
Verification evidence
The Tester checks completed work against requirements and success criteria, then keeps the evidence visible in the record that best matches what was learned.
Use Task entries for verification notes tied to build work.
Use review notes when the check reveals useful input on a requirement.
Use Risk when a test result exposes uncertainty or possible harm.
Do not create a Change record merely because testing is happening.
Run the service safely
The Operator manages run-side change, incidents, problems, operational inventory, rollout and rollback planning, monitoring, users, permissions, settings, provisioning, and run-side security.
Use Change for a discrete alteration to the running service, with execution and rollback plans.
Use Incident for a specific service-impacting or potentially service-impacting occurrence.
Use Problem for an underlying or recurring cause evidenced by incidents.
Use Environment for named operating contexts such as local, staging, or production.
Use Component for environment-specific apps, databases, queues, storage, external services, and other operational items.
Use Maintenance Schedule for recurring checks, reviews, rotations, or maintenance duties.
Record where secrets are stored and what they are called, not the secret values.
Route user signals
The Support Agent helps users, captures questions and reports, and routes signals into shared follow-up only when a shared record is needed.
Use Support Request for a user-facing question, report, request, or issue that needs shared follow-up.
Use DX Complete Ticket for questions, reports, requests, corrections, or follow-ups with DX Complete itself.
Promote to Statement, Requirement, Task, Incident, Problem, Risk, Decision, Change, or Journal only when the signal has that meaning.
Do not create process records just because a user said something. Create them when the signal has work, risk, decision, or service-control meaning.
Input, not operation
The End User uses the service and provides requests, feedback, corrections, and issue reports. Another role captures that input when it belongs in DX Complete.
Statement, report, request, correction, feedback signal, or ticket.
End User feedback is not authority approval unless that person is also acting in an authority role.
Internal and external users
DX Complete derives access from workspace roles. Owner, Engineer, Tester, Operator, and Support Agent are internal roles. End User is external only when it is the person's only role.
The submitter, internal users in the workspace where it was filed, and DX Complete internal support can see the ticket. Other End Users cannot.
The filing End User and internal users can see the support request. Other End Users cannot.
Tasks are work records for internal roles.
Dev Log entries show code-history context for internal roles.
Signed-in members can review the phases, attention counts, cross-phase records, and record links they are allowed to see without changing them.
Internal users see the full workspace action set for their role. End Users are offered only their own Support Request actions.
Choosing the right record
Use Task as the internal work-order record for concrete work someone needs to do. It can be assigned to a role, a named person, both, or neither.
Use Decision when alternatives were considered and the choice should remain legible.
Use Risk when something uncertain could affect value, delivery, service, or compliance.
Use Change for a discrete alteration to the running service.
Use Incident for a specific service-impacting occurrence that needs response history.
Use Problem when one or more incidents point to a deeper or recurring cause.
Use Support Request for a shared user-facing support thread.
Use Environment and Component for what exists, where it lives, and which secret locations matter.
Use Maintenance Schedule for recurring service hygiene.
Use Value Realization for before-and-after metrics tied to expectations, requirements, or commitments.
Use Dev Log for internal context about what landed in the workspace repository.
Use Journal only when the context has no better dedicated record home.
Use DX Complete Ticket for communication with DX Complete.
The simplest test is: will anything reference or depend on this? If yes, use the dedicated record that can carry that relationship.
Use service records only when they fit
Change is the current first-class run-side control record. Use it for a specific alteration to the running service, with a change type, plan, execution path, rollback path, risk, and event history.
Incident is for a specific service-impacting or potentially service-impacting occurrence. Problem is for an underlying or recurring cause evidenced by incidents. Do not create service-control records merely because work is happening; use them when the service-control meaning fits.