A journal you can ask to change

A fictional team wanted a shared journal. An existing owner submitted the guarded request in Composer, and the supported path reached a published Guestbook on the shared app runtime. You can open the result and inspect the app itself.

Open the Fictional Atlas team journal.

Change the name. Keep the app.

The follow-up changed its title to Fictional Atlas team journal. Composer completed that supported update under the owner’s saved standing policy, revision 1, without asking for a separate approval. It kept the original resource. This was an update to the same app rather than a second journal.

A policy is useful when it makes that boundary predictable. In the same native release review, a request requiring Australian-only placement stopped as unsupported and produced no service link. The shared runtime did not become an Australian-only deployment by implication.

One existing owner in a fictional workspace on the shared app runtime. New-customer admission, invited-member contributions, dedicated team infrastructure, incident recovery, restore and retirement are outside this proof. Public postcards remain closed. Public moderation sharing is unsupported; an approval is not an Open.

The earlier Harbour Notes example answers a different question: an owner can approve a pending note and pause new arrivals while the approved note stays public. It remains available with its own dated evidence. Neither example supplies a public approval-count report.

Inspect the separate Harbour Notes example.

The Atlas app currently has postcards closed and no published moments. Visitors can inspect the result; authoring and policy controls require the existing owner’s authorised account. Start from Composer’s practical introduction if you want to understand the broader build path.

Explore App Composer.