What Update Requests are

An Update Request is the canonical channel for team members to propose a change to the brand record. They are structured, attributed, recorded, and accountable. Update Requests are how the team brings gaps, contradictions, and clarifications to the brand owner without resorting to email and without making improvised local edits.

​

Why Update Requests exist

A working brand has a constant stream of small questions. Is the secondary blue the same as the one in the press release? Should the headline weight on Instagram be Bold or Semibold? We need a new template for partnerships; who owns that? Without a channel, the team handles each question in one of three ways:

1. They guess. The guess becomes a local precedent. Multiplied across the team, this is how brand drift starts.
2. They email the brand owner. The email is lost in the inbox; the answer (if it comes) is not recorded; the next team member with the same question has no way to find the prior answer.
3. They give up. The team stops engaging with the brand; the brand becomes whatever each person remembers.

Update Requests give all of this a structured surface. The team raises the request inside the section it concerns; the brand owner answers inside the portal; the change is recorded; the brand record learns from the exchange.

​

What an Update Request contains

Every Update Request has the same five fields:

1. Section or Horizon. Where the request is raised. The system knows from context, but the team member can change it before submitting.
2. What is proposed. A free-text description of what should change. The team member writes this in their own words.
3. Why. The reason behind the proposal. Useful context that helps the brand owner decide.
4. Supporting material. Optional attachments: a file, a paste, a screenshot, a link. Attaches the evidence to the request.
5. Suggested wording or value (optional). If the team member wants to propose specific text or a specific value, they can include it. The brand owner can accept the suggestion as-is, edit it, or replace it.

​

How requests are routed

Every Update Request goes to the brand owner’s Inbox. On Guardian, the brand owner can configure routing rules: requests on specific sections can route to a delegated Editor for first review, with the brand owner approving the final apply. A request can be reassigned, snoozed, escalated to MadeBy_, or routed to Oswald (Guardian, in beta) for drafting.

​

The four possible outcomes

A request ends in one of four ways:

1. Approved and applied. The proposed change is merged into the brand record. The team member is notified; the brand record’s history records the change.
2. Approved with edits. The brand owner edits the proposal before applying. The team member is notified with the final wording.
3. Rejected with a reason. The brand owner declines and explains why. The team member is notified; the request remains visible in history with the reason.
4. Escalated. Routed to Oswald (for drafting), to MadeBy_ (for studio input), or held pending external decision. The team member is notified of the escalation.

Closing without a response is not a valid outcome. Every request gets an answer.

​

What Update Requests are not

Three patterns where Update Requests are the wrong tool:

• Conversations about strategy. A request to redesign the brand’s positioning is not an Update Request; it is a conversation that happens outside the portal. Update Requests are for concrete edits to the brand record.
• Bug reports. Issues with the product (a section that will not load, an editor that crashes) belong with support. The Update Request channel is for the record; the support channel is for the product.
• External design work. A request to “design a new template” is a brief, not a request. Treat it as a project and bring the result back as a request to add the finished work to the atlas.

​

Update Requests on the brand owner side

A brand owner reviewing requests has three tools:

• The Inbox. The list of all open requests, sortable by section, age, or requester.
• The request page. The full request with all context, the current state of the section, and the apply controls.
• Bulk actions. Approve, reject, or reassign multiple requests at once. Useful at the end of a review cycle.

See Reviewing and approving for the working flow.

​

Update Requests on the team-member side

A team member raising requests has:

• The Raise Update Request button. Present on every section and Horizon (on Keeper and Guardian).
• The request status. Pending, in review, approved, rejected, escalated. Visible in the team member’s own Inbox.
• The history. All requests the team member has raised, with their outcomes.

See Submitting (team view) for the team-side flow.

​

Related pages