Organization uploads and team access

An organization is your enterprise workspace. It contains teams, repositories and their application assessments. An organization ingestion token lets trusted CI jobs or local CLI runs send assessments for multiple repositories. Each upload names a stable repository key; reports and scores stay separate for each repository and app.

The existing repository credential remains available. Choose it when a workflow should write to only one repository. Both credential types are for uploading; dashboard access uses email/password sessions and team membership.

Set up your organization

1. Sign in at Lattice Cloud as the organization owner.
2. In Organization settings, create teams and assign each repository to its owning team.
3. Give central reviewers organization access. Give team users team access with the specific teams they may read. A user can belong to several teams.
4. Create an ingestion token with organization scope. Enable automatic repository registration if new repositories should appear on their first upload.
5. Copy the token once into your CI secret store as LATTICE_INGEST_TOKEN. Use a normal, non-secret variable for each repository’s stable key.

An organization token can submit reports to every repository in that organization. Keep it in trusted centrally managed workflows; do not distribute it as a dashboard credential. Rotation creates a replacement; update CI before revoking the old token. Expired or revoked tokens stop accepting new requests.

Send reports from multiple repositories

The legacy organization-upload path remains compatible with CLI 0.10.0 or newer; use the current pinned 0.11.1 package with Node.js 24+. After installing the pinned CLI, run:

# LATTICE_INGEST_TOKEN is supplied by the environment or CI secret store.
pnpm exec lattice report push .nklattice-governance/assessment.json \
  --server https://app.lattice.getgroove.me \
  --repository web/customer-portal --dry-run

Review the sanitized preview, then remove --dry-run to upload. In another repository, run the same command with --repository web/admin-console and the same token. Independent CI jobs can run concurrently. A monorepo report contains its app results without needing additional credentials per app.

--repository selects the new upload mode and reads LATTICE_INGEST_TOKEN. --project-key selects the existing repository mode and reads LATTICE_UPLOAD_PASSWORD. Choose one mode per command. An explicit legacy command keeps its behavior even if the new environment variable is present. Dry-run is offline and needs no credential.

Repository keys identify destinations within one organization. They are stable, non-secret identifiers, separate from display names. Use reviewed aliases if repository names are sensitive. The CLI does not silently publish your Git remote URL. The same key in another organization refers to that organization’s separate repository.

Must the repository exist first?

If the token permits automatic registration, the first valid upload creates a pending repository when its key is unknown. The owner can review its report immediately, assign a team and approve the policy SHA and expected app inventory. Pending repositories are visible to central owners, and they do not establish compliance by uploading their own baseline.

If automatic registration is disabled, create or import the repository before uploading. An owner can import a reviewed manifest in bulk, previewing creates, attachments and updates before applying them. To give a new key to an existing repository, use its explicit existingProjectId; this preserves report history and legacy credentials. Matching by display name is not a migration method.

Team accounts and visibility

Account	Can read	Can configure
Organization owner	All organization repositories, including pending and unassigned	Teams, members, baselines and credentials
Organization viewer	All organization repositories, explicitly granted	Own account only
Team viewer	Repositories assigned to their permitted teams	Own account only

The owner creates a one-time account activation and shares it through an internal secure channel. The recipient sets their own password; the link expires after 24 hours and cannot be reused. Existing accounts in the same organization keep their password when their access scope changes. An account in another organization cannot be silently moved by assigning a team.

When restricting an existing organization viewer, explicitly change their access scope to teams and select memberships. Merely adding a team does not remove organization-wide permission. Public self-registration creates a separate workspace; it does not join a team in an existing enterprise.

The server checks current membership on data requests, including report detail and metrics. Users with no team membership see no team data. Repository reassignment changes which team can read its history; historical views use current ownership.

Read metrics across teams and repositories

The shared filters select teams, repositories, apps, framework, domain, status and time. Owners can compare multiple teams and repositories; team users only see authorized choices. Overview, signals, findings and report history follow the same permitted selection.

Current compliance uses the latest eligible default-branch CI assessment, approved policy identity, expected app inventory, evidence completeness and freshness. Local uploads remain available as observations/history. Compliance is the number of compliant enrolled apps divided by the selected enrolled app population; it is not an average of repository percentages. Pending setup, missing evidence and unscanned apps remain visible.

When selecting one app in a monorepo report, distinguish its selected-scope status/counts from the original full report. Selecting a domain explains that domain’s result; it does not turn a partial scan into overall governance compliance. Report activity uses receipt time, while current posture uses the latest eligible assessment.

An upload credential proves permission to submit, not the claimed repository origin or CI commit. Reports continue to be labeled as client-submitted evidence. Token rotation never changes the repository’s identity or resets its report history.

The initial v2 limits are 120 upload attempts and 20 auto-registered repositories per minute per organization, shared across its tokens. A limit returns HTTP 429 with Retry-After: 60. Import a large reviewed inventory before its first scan or spread first uploads over time; preserve failed-upload alerts in CI so reports are not silently skipped.

See CLI commands, AI agent setup and project governance for the scan workflow.

Provenance and owner operations

After release verification and operator activation, assessment2 uses payload3/envelope4. The client checks capabilities before upload; unsupported security contracts fail closed, never silently downgrade. The bundled scripts/security-upload.mjs helper is shipped with the verified npm package; no raw private-GitHub download is required. Inspect its help and use an owner-controlled workflow. --provenance github-oidc is explicit and needs actual GitHub workload variables, single-use server challenge, exact payload digest and owner-approved binding. Upload-token possession alone yields no verified provenance. Keep workload credentials out of the job that executes untrusted repo modules.

The original receipt records narrow verified scope; current report trust can later become ineligible without changing it. Password login remains; OIDC is workload identity only. Model/waiver approvals, secret rotation, holds and lifecycle apply require current owner authorization and appropriate recent-auth. Operations explains metering, deferred webhook setup, retention and isolated recovery. Do not enable public v3 before the operator and registry gates pass.