Find our project, document and reporting desks in the services directory. Developers can use our API guide and RSS feed.
Blog
-
A short checklist before closing a ticket
Confirm the reported problem, describe the resolution, and leave a usable pointer to any changed guide or record. A closure note should help someone recognize the same problem if it returns.
If the outcome depends on another team, record their ownership and the agreed next step. Closing the local ticket should not make an unresolved dependency disappear.
-
Handling a corrected attachment
A corrected attachment should explain what changed and retain the request or document reference. That lets the reviewer compare the new revision with the earlier decision.
Avoid replacing an approved file silently. Upload the revision, add a brief note describing the correction, and return the record to review if the change affects its meaning.
-
Notes from a delivery review
The most useful review questions concern the actual deliverable: can the next team find it, open it, and understand what it covers? Review notes should point to the revision that was opened and to any assumptions that still need confirmation.
A milestone can be ready for handoff while a separate question remains open. Record the boundary explicitly so the next owner does not infer a broader decision than the review supported.
-
Keeping service owners visible
A service record should have an owner who can explain where requests go and what a paused route means. The route address alone is not enough for the team member investigating a failed handoff.
When a route changes, leave a note with the reason and the next validation step. A successful response from a gateway confirms transport; the destination team still owns the result of processing the request.
-
Reading an intake receipt
The intake endpoint returns a reference when a submission has been accepted into the queue. This is useful when someone needs to check on a request or send a corrected attachment. It is not an approval or a delivery commitment.
Keep the original reference when replying to a request for more information. A second submission is appropriate for a different piece of work, but it creates avoidable review work when it is merely a retry of an accepted submission.
-
Small handoffs that prevent repeat questions
A handoff should answer what changed, who needs to act next, and where the supporting material lives. The purpose is to let someone continue the work without recreating the whole conversation.
Before closing a milestone, check its linked deliverables and name the team that owns the next step. If an outstanding question remains, record it as an open item rather than hiding it in a completion note.
-
What a document review should leave behind
A useful review leaves three things: a named owner, a clear decision, and a reference to the revision that was considered. Comments that say only “looks good” do not explain what is ready for the next person.
When a document needs changes, identify the section and describe the expected result. Keep the previous revision available until the new one has been accepted. The document register records Pending review, Approved and Needs changes separately from the discussion.