Mozaic
Sign inStart free
Publication and outside contribution

Expose exact public views, never implicit access.

Mozaic starts organizations, projects, and repositories private. Publication is a sequence of independent gates. Anonymous visitors can read only deliberately public resources; authenticated outsiders can report work, create a private fork, and propose an exact snapshot.

Private-firstIndependent ancestor and descendant gatesExact-snapshot contribution
PublishReview impact, verify identity, acknowledge, and confirm the exact slug.
ReadAnonymous views expose only separately published descendants.
ContributeSign in, fork privately, and open an immutable proposal snapshot.
Security model

Understand the visibility chain

Organization gate
Creates an anonymous public namespace. It does not publish any project or child resource by itself.
Project gate
Makes the project identity, summary, public activity, and separately public descendants eligible for anonymous reading.
Descendant gate
Repositories, Knowledge, work, packages, and other child views retain their own visibility decision.
Write access
Always passes through authentication and authorization. Public read never grants public mutation.
All required gates must agree.

A project with a recorded public choice behind a private organization is shown as Blocked by organization. A public organization still leaves every private project and descendant protected.

Workflow 1

Publish the organization namespace

Permission and security

Manage organization and a recent passkey, security-key, authenticator, or recovery-code check are required.

Organization›Settings›Organization›Public access
  1. Wait for the impact inventory.Mozaic loads every project when needed so it can identify recorded project publications that would immediately become reachable.
  2. Choose Review public access.Read the exact resource, URL namespace, write-access boundary, audit behavior, and ancestor/descendant effect.
  3. Verify identity.If the page says fresh authentication is required, choose Verify identity, complete the security check, and return to Public access.
  4. Acknowledge anonymous internet access.Confirm that anyone may read permitted public information and that already-downloaded copies cannot be recalled.
  5. Type the exact organization slug.The final action remains disabled until the acknowledgement and slug both match.
  6. Make organization public.The change is audited and the anonymous namespace becomes eligible.

Success state

Public access displays Public and identifies the organization as a public ancestor. Existing separately published projects become reachable; private projects do not.

Workflow 2

Publish a project

Permission and prerequisite

Manage projects and fresh authentication are required. The owning organization must already be public unless the project has only a preserved publication record from an earlier state.

Organization›Projects›Project›Settings›Project›Public access
  1. Review the prerequisite.If the organization is private, follow the Organization settings link; merely opening it changes nothing.
  2. Review public access.Confirm the exact public URL and that working drafts and private descendants remain protected.
  3. Verify identity and acknowledge impact.Complete the fresh security check and internet-access acknowledgement.
  4. Type the project slug.Confirm the exact project boundary.
  5. Make project public.Use View public page from the resulting settings state to verify anonymous presentation.

Success state

The project reports Anonymous read access is enabled and provides its public URL. Only descendants already carrying their own public choice appear.

Anonymous reading

Know what a public visitor can see

A public project landing page can present the project summary and immutable summary history, published Knowledge and revision history, public repositories, verified package releases and provenance, trusted builds, milestones, visible work, and public activity. Each section is authorization- and visibility-filtered; an empty section can truthfully report that no visible activity has been recorded.

Other public surfaces

Public News
The organization's public News feed and article routes expose published articles and their published history, not drafts or campaign operations.
Public repository
When an independently public repository already exists beneath public ancestors, visitors can browse and start the Fork workflow.
Public pull request
Readers can inspect source/target, exact snapshots, commits, reviews, and checks. The authenticated author may refresh the proposal to an exact current source revision.
Current repository-settings limitation.

The current repository Settings › Access surface is informational and does not offer a publication change. Repository creation is private. Do not expect project publication to expose a private repository.

Workflow 3

Submit work from a public project

Authentication

Anonymous visitors can read, but submitting a Bug, Feature, or Private security report requires a signed-in account.

  1. Open the public project.Choose its work-submission action.
  2. Sign in if requested.Mozaic returns to the public project after a safe account handoff.
  3. Choose the submission type.Select Bug or Feature for visible public work, or Private security report for restricted disclosure.
  4. Enter title and rich description.Do not place secrets in ordinary Bug or Feature submissions.
  5. Submit.Public work returns the created resource where policy permits. A security report returns a private acknowledgement and opaque reference only.

Private-report success state

The page says Private report received and shows an opaque reference. The report contents are not echoed into the public project.

Workflow 4

Fork a public repository privately

Public repository›Fork
  1. Sign in and secure the account.Complete strong authentication if the guided flow requires it.
  2. Choose the target project.The fork belongs to a project in an organization you control. If none exists, Mozaic guides you through creating a private organization/project context first.
  3. Name the fork.Confirm repository name and slug.
  4. Review ownership.Verify the source relationship and that the new fork remains private.
  5. Create fork.The receipt opens the private repository and offers the contribution path back to the source.
Outside contribution does not grant target membership.

The contributor owns the fork in their organization. The target receives an explicit proposal snapshot, not hidden access to either organization.

Workflow 5

Open a cross-organization contribution

Private fork›Contribute
  1. Review boundaries.Confirm the source organization/repository and target organization/repository.
  2. Select source and target refs.Mozaic resolves the exact revisions and merge base.
  3. Write the proposal.Enter title and rich description; optionally mark it Draft.
  4. Review the snapshot.Inspect the exact source, target, and merge-base revisions before opening.
  5. Open contribution.Mozaic pins the immutable snapshot and returns a receipt with target, source, snapshot, and status.
  6. Refresh explicitly after more pushes.A branch update does not silently alter the proposal. The author chooses to refresh to another exact source revision, which creates a new snapshot and invalidates evidence tied to the previous one.

Success state

The target public pull-request page shows the exact snapshot under review. Continue with the Pull requests guide for comments, approvals, checks, suggestions, and merge policy.

Workflow 6

Return an organization or project to private

  1. Open the same Public access destination.Choose Review private access.
  2. Read descendant impact.Organization privacy immediately blocks every project's anonymous reachability. Project privacy blocks the project and its descendant reads.
  3. Verify identity.Complete a fresh security check when requested.
  4. Type the exact slug.Confirm the specific organization or project.
  5. Make private.Mozaic invalidates current public cache/discovery and records the action.
  6. Review preserved child choices.Descendant publication records are not reset. Clear unintended project choices before any future organization republish.
Copies cannot be recalled.

Returning private stops current Mozaic anonymous access, but content already downloaded, indexed, or copied by another person remains outside Mozaic's control.

Troubleshooting

Common publication and contribution failures

Review public access is still waiting

Mozaic has not finished inventorying all projects, or an inventory request failed. Use Retry inventory; publication stays unavailable until the impact statement is complete.

The project cannot be published

The organization is private, your role lacks project-management permission, or fresh authentication expired. Publish the organization separately or ask the appropriate manager.

A published project says Blocked by organization

Its publication record is preserved behind a private ancestor. Republish the organization only if intended, or clear the project's record while it remains blocked.

Fork has no target project

Create or select a private project in an organization you control. The guided Start flow can create that ownership context without changing the public target.

The contribution no longer matches the branch

This is expected: review is pinned. Choose Refresh exact source to create another snapshot; previous approvals, checks, and execution grants may no longer apply.

A public child is missing

Project publication does not publish repositories, working Knowledge, packages, or work automatically. The child must have a supported independent public state, and every ancestor must be public.

  • There is no visibility selector during organization, project, or repository creation.
  • Anonymous access is read-only.
  • Working Knowledge drafts are never substituted for published checkpoints.
  • Public security-report responses never reveal the report body.