Manage Productivity Repositories

Tasks

Manage repository discovery and collection under Settings → Productivity → Repositories. Administrators change onboarding settings and decisions; viewers can inspect inventory, collection health, and history.

Connect your GitHub integration first. A connected integration with no onboarded repositories is a setup state; it does not mean that GitHub credentials are missing. See repository scope and discovery for how this affects coverage.

Configure discovery and onboarding

1. Open Settings → Productivity → Repositories and select Configure.
2. Choose an onboarding mode: Manual for explicit additions, Discover and review for a pending queue, or Automatic for eligible discoveries to be onboarded automatically. Existing installations retain their migrated Manual scope; new configurations start with Discover and review.
3. Choose Observed in sessions, GitHub inventory accessible to this integration, or both. Automatic requires at least one source. Session discovery finds observed gateway activity. GitHub inventory finds credential-visible repositories even if no developer session has used them.
4. Enter Allowed owners, one GitHub organization or user per line. An empty list never means all owners. Optionally add Include patterns and Exclude patterns in owner/name form, such as acme/* and acme/sandbox-*. Use * as the wildcard.
5. Choose whether automation may include forks and archived repositories, and set the initial collection history. The default is 90 days. Manual onboarding can override the fork/archive defaults but cannot bypass owner scope or exclusions.
6. Select Preview changes. Review the candidate counts and any onboarded repositories whose collection would pause after a scope change. For Automatic, choose whether to apply promotion to future discoveries only or also to eligible pending repositories in the preview. Explicit skips and review holds are preserved.
7. Select Apply settings. Use Discover now to request discovery from the enabled sources. The operation drawer shows progress and any per-repository failures.

Narrowing owner or pattern scope pauses collection for affected onboarded repositories without changing their onboarding decisions. Expanding the scope can resume eligible collection after access verification. GitHub permissions and AIControls collection scope are separate controls.

Review discovered repositories

1. Open Pending review. Search by repository name or filter by owner, discovery source, collection status, access, or scope. Filters, pagination, and sorting are retained in the URL.
2. Open a repository to inspect its identity, discovery evidence, last session activity, scope, access, collection state, and decision history. A GitHub inventory observation is not a developer session.
3. Select repository checkboxes, then choose Onboard or Skip. To act on every matching repository across pages, choose Select all … matching repositories.
4. Review the server-generated preview. The selection is frozen at preview time; new discoveries are not silently included. Counts that still require provider verification are marked as estimates. Confirm the action before the preview expires.
5. Inspect the operation's progress and paginated results. Concurrently changed rows are reported as conflicts. Refresh the inventory and preview a new selection to retry those rows.

An onboarded repository can still need GitHub access or remain outside scope. The decision, scope, access, and collection states remain visible independently. Onboarding automatically includes the repository in every enabled productivity feature. Project membership remains separate.

When switching to Automatic or expanding its scope, the preview can include candidates that still need GitHub access verification. Choose Also authorize eligible pending repositories in this preview to include them. Verified candidates onboard; the others remain Pending review with an Awaiting verification operation result. This is a recorded authorization, not a successful onboarding. If access is denied, they stay pending; restoring access can complete onboarding while the current policy still permits it. Disabled discovery sources, disabled onboarding, review holds, skips, and exclusions are not bypassed.

Repositories whose decisions are preserved, including skipped or held candidates, are reported as unchanged rather than successful onboardings.

Saving this choice opens the durable operation. Its URL can be reloaded to inspect progress and results. The awaiting-verification count records the authorization result at processing time; open the repository to see its current access and collection state.

Inspect recent commit evidence

All three tabs—Onboarded, Pending review, and Skipped—show Last observed commit with the commit date and Git committer. Select the column to sort by commit date; repositories without evidence remain last. Open the repository for the branch, commit link, observation time, and GitHub push actor.

Enable Push events on the GitHub webhook configured for the integration. AIControls records branch-tip commits from authenticated push events for repositories whose GitHub identity is already verified. Tags, branch deletions, and repositories with no observed commit display no new commit evidence. Existing history is not backfilled by this view.

Coverage is limited to observed pushes across branches. A missing value means No commit observed, not that the repository is inactive. Observation time indicates when evidence arrived; it does not prove that every subsequent push was received. Commit dates and committer names are Git metadata and can differ from the GitHub account that sent the push.

Push observed since skipped means a new, deduplicated push payload was recorded after the latest skip decision. This ordering is independent of server clock differences. Delayed delivery can describe an earlier push. Receiving metadata never restores a skipped repository or starts PR history collection, scoring, or assessment. Redelivering an already recorded payload does not refresh the indicator. Older metadata without recorded decision ordering does not set the indicator.

Browse GitHub in Manual mode

1. Select Browse GitHub. This opens the stored inventory visible to your integration without onboarding it.
2. If no scan is available or access recently changed, select Refresh GitHub inventory. Inspect the queued operation, then reopen the browser after it completes. In Manual mode, the scan does not create automatic pending candidates.
3. Search and select repositories across the server-paginated results, then select Preview selected imports.
4. Review eligible entries, exclusions, and sticky skips, then confirm the import. GitHub accessibility does not override your configured collection scope.

Add repository names in bulk

1. Select Add repositories in any onboarding mode.
2. Paste owner/name entries or GitHub HTTPS/SSH remote URLs, separated by commas or new lines. Alternatively, choose Import text file for a text or CSV file containing those entries.
3. Select Preview import. Check normalized names, invalid entries, duplicates, existing repositories, excluded entries, and skipped repositories.
4. Confirm the eligible additions. A valid in-scope repository can be onboarded while access verification is pending. An already-skipped name requires an explicit restore and cannot be reactivated by import.

Import requests are limited to 1 MiB, including text encoding. The dialog checks pasted text and uploaded files before previewing. If an import is too large, split the entries into smaller batches.

Imports accept a list of entries, not a spreadsheet with additional columns or a CSV header. Fix invalid names and adjust scope explicitly before retrying excluded repositories.

Skip and restore repositories

1. In Onboarded or Pending review, use a repository's action menu or select multiple rows and choose Skip.
2. Review the effect and confirm. Skip stops future GitHub collection and productivity processing for those repositories. Previously collected history and published reports remain available.
3. To reverse the decision, open Skipped and choose Restore to review or Restore and onboard.
4. Use Restore to review when another review is needed. It places the repository in Pending review with a review hold, including in Automatic mode. Later, choose Onboard or Release review hold explicitly.

Skip survives rediscovery, mode changes, and restarts. It is not a history-deletion operation and does not disable normal session capture or governance.

Prepare repository release branches

Release-branch configuration is staged separately from onboarding. Newly onboarded repositories inherit workspace release defaults. Without workspace defaults, they start with a snapshot of their verified provider default branch. If that branch is unknown, configuration remains needed; AIControls does not assume main. A provider default-branch rename does not replace the snapshot.

Configure workspace defaults

1. In Workspace release branches, select Configure release defaults.
2. Add exact names such as release/4.24 or patterns such as release/**. An exact name selects only that version; a pattern can also select future matching versions.
3. Leave Also use defaults for existing repositories without custom release rules selected to adopt defaults for verified repositories with no configuration or untouched initial rules. Manually edited policies and explicit overrides stay unchanged.
4. Select Preview affected repositories. Review repositories already inheriting, adopting defaults, preserved, or awaiting verification. Search, sort by repository, onboarding decision, or configuration impact, and paginate through the list to inspect the resulting rules.
5. Select Apply release defaults. If relevant repository configuration changes or the 15-minute preview expires, create a new preview. Previews support workspaces with up to 10,000 canonical repositories.

Inheriting repositories follow subsequent workspace updates automatically. Changing release/4.24 to release/4.25 updates their effective rules without editing each repository. Workspace changes keep their own revision history and never change onboarding decisions, authorization, or collection. Newly onboarded repositories can inherit staged rules while provider verification is pending. This does not make them eligible for collection or branch inventory. Verification is required before existing legacy configuration can adopt defaults.

Override one repository

After GitHub identity verification, administrators can configure multiple exact names and patterns such as release/** from repository details in any of the three decision tabs. Viewers can read saved rules and preview their matches.

1. Open a repository and find Release branches.
2. Select Override release branches for an inheriting repository, or Edit release branches for an existing override. For each rule, choose Exact name or Pattern and enter a case-sensitive short branch name or pattern. Select Add release rule for additional branches.
3. Use * within one path segment, or ** across segments. For example, release/** matches nested release branches. Overlapping rules count each matching branch once.
4. Optionally enter a change reason, then select Save release branches. If another administrator has changed the saved rules, your draft stays visible and the save is rejected. Select Discard edits to load the latest saved rules before editing again.

You can save 1–64 rules. Each name or pattern is limited to 255 UTF-8 bytes, with a combined limit of 4,096 bytes. Empty policies cannot be saved. Saved configurations retain revision history. Saving rules for a skipped repository does not restore collection. Bulk imports inherit defaults on first onboarding. An override replaces the entire workspace list; it does not add to it. Select Reset to defaults, review the change, and save to resume live inheritance. Without workspace defaults, reset snapshots the current verified provider default branch or leaves configuration needed if it is unknown.

Staged configuration

Saved release rules are not yet applied to productivity scores, PR counts, or reports. The API reports activationStatus: staged and scoringStatus: unchanged. Scoring activation and retained-history recalculation remain a separate step; saving defaults or adopting them does not recalculate history. Continue using the evaluated-report scope controls below for current report selections.

Preview branch matches

You can preview prospective rules before saving them, or preview the saved rules without entering edit mode.

1. Ensure the GitHub App or fine-grained token has Contents: Read-only access to the repository.
2. As an administrator, select Refresh branch inventory in the repository's Release branches card. This queues a scan without changing onboarding decisions.
3. Wait for the inventory status to change from Collecting, then check its observation time and completeness.
4. Select Preview matching branches. Use Next branches and Previous branches to browse the results. Changing a draft rule clears its previous preview.
5. If the inventory, repository policy, inherited workspace defaults, or cursor changes, check the refreshed rules and inventory status, then preview again. If saved rules changed while you were editing, your draft stays visible; select Discard edits to load the latest saved rules. A preview never saves your edits.

A preview lists matching branch names once, even when rules overlap. It uses a stored scan and does not contact GitHub or save your rules. It does not estimate PR counts or score changes. Refreshing a skipped repository leaves it skipped. If a metadata reload fails, use its retry action before starting a new preview. When repository access is unavailable, stored branch names and counts are hidden; verify access and refresh the inventory before relying on its results. Restoring access or a previous repository name does not restore the old scan; select Refresh branch inventory after access is verified again. If GitHub reports that a repository was replaced during a scan, the scan is cancelled and its previously observed names are removed. Verify the repository's identity and refresh its branch inventory before previewing again. If repository details report an access or identity change while the drawer is open, old branch results disappear immediately. Unsaved rule edits stay intact. Starting a save, refresh, or new preview also clears the previous preview while the request is pending. Saving the GitHub connection in this session also clears cached branch results. Changes made in another session appear on the next inventory refresh; the server rejects previews from the previous connection immediately. An open, active drawer checks saved rules every 30 seconds. If another administrator changes them, the previous preview clears and your unsaved edits stay visible. Select Discard edits to adopt the latest rules.

Check the inventory state and warnings before interpreting the count. Scans cover at most 10,000 branches and become incomplete if interrupted or if GitHub changes the branch count during traversal. A complete scan becomes stale after 15 minutes. Scans observe branches over a time window, not at one instant. When coverage is incomplete, stale, unavailable, or includes unsupported names, matchCount is null; matchedObservedCount describes only observed matches. A missing inventory never means zero matches. The UI displays an unknown count with the number of observed matches in these cases. Credential changes require a fresh scan.

Set evaluated-report scope

1. Open Settings → Productivity → Outcomes and expand Repositories & branches.
2. Select Select onboarded repositories. Search and select rows across pages. Evaluated reports retain the existing limit of 200 explicitly selected repositories.
3. Select Review selection. New selections include all target branches by default. Opt in to Use suggested default branches for these new repositories if appropriate, then select Confirm selection. Existing branch choices are preserved.
4. For each repository, keep All target branches or choose Selected target branches and select or enter up to 100 exact names. Existing single-branch selections stay unchanged until you edit them. Branch suggestions can be incomplete; exact names can still be entered.
5. Review collection warnings for selected repositories. Skipped, inaccessible, unknown, or out-of-scope selections remain visible. Restore collection or explicitly use Remove from report; discovery never silently changes this selection.
6. Preview and publish the rule version with a reason. Onboarding changes do not modify an existing published report.

Activate an upgraded installation

An upgraded installation can show Repository onboarding awaits coordinated activation. The administrator must coordinate this step with the deployment operator. Stop older gateway replicas and repository workers, deploy the new release everywhere, and review the migrated repository scope before selecting Review activation. Read and select the acknowledgment, then choose Activate repository onboarding. The acknowledgment does not stop replicas automatically. A fresh installation does not require this upgrade confirmation.

Resolve collection problems

1. Use the help buttons beside Access, Collection, and Scope to see each column's values and meaning. Each decision tab also explains which repositories appear there.
2. Filter Access status to find credential problems, or choose Collection status → Needs attention for failed or repeatedly failing collection jobs.
3. Open a repository. The list and drawer update every ten seconds. Check Last success separately from the current job: a queued refresh can coexist with successful earlier collection.
4. Inspect the collection stage, PRs processed, PRs discovered so far, job request time, attempt count, and error. Discovery can find more PRs as pagination proceeds, so these counts are not a completion percentage. A retry's Retry available from timestamp is its earliest eligible time; it may still wait for a worker or shared request capacity.
5. For a retrying or failed job, choose Retry failed to resume from its saved checkpoint and release retry backoff. A running worker continues uninterrupted. Choose Scan now when you need to collect a chosen history window again.

State	Action
Needs access or access unverified	Confirm the integration credentials and GitHub installation/token access. Restoring access preserves onboarding intent.
Outside scope	Review allowed owners and include/exclude patterns. Explicit onboarding does not override scope.
Review hold	Onboard explicitly or release the hold after review. Automatic does not bypass it.
Initial sync queued or Refresh queued	Waiting for a worker or retry time. Existing successful results are retained.
Initial sync running or Refreshing	A worker is collecting data. The drawer shows its stage and counts.
Retrying	A step failed and will retry from saved progress. A transient retry alone does not mean Needs attention.
Needs attention	A job failed, or has a repeated error after at least five attempts since its last successful step. Queued jobs continue retrying automatically. Open the repository for details and use Retry failed if appropriate.
Error	Read the repository's error. Request timeouts retry automatically from saved progress; successful collection steps clear the error. For persistent failures, review the error and use Retry failed for eligible onboarded repositories.
Preview expired or version conflict	Refresh and generate a new preview. Conflicting decisions are not overwritten.
No onboarded repositories	Configure owner scope and discovery, review pending candidates, or add repositories manually.

Collection processes bounded chunks and gives other waiting repositories a turn between chunks, so a large history does not monopolize collection. Completed chunks reset transient-failure backoff and preserve progress across worker restarts.

Repository details show outstanding collection failures before newer completed PR refreshes, so a successful single-PR refresh does not hide a stalled history import. Large review-comment responses retry with smaller pages while retaining the same position and the 300-comment collection cap. If even a single-comment response exceeds the limit, the error identifies the GitHub endpoint and collection retains its progress for retry.

If refreshing productivity file statistics fails, existing usable totals for the same PR revision remain available. PR metadata still updates; PRs without usable totals show an unavailable score until statistics can be collected.

Waiting for shared request capacity keeps collection queued and does not increase failure backoff. GitHub rate limits delay collection until the retry time shown in the repository details. Neither wait discards collected progress.

See GitHub connection troubleshooting for authentication and webhook setup.

Scan and retry one repository

1. Open an onboarded repository and inspect its collection progress and last successful collection. Feature processing shows productivity file statistics and assessment counts.
2. Select Scan now. Choose the last 7, 30, or 90 days, or a custom duration of up to 365 days.
3. If a job failed or is waiting to retry an error, select Retry failed to resume its checkpoint. Other repositories continue processing independently.
4. Use Sync selected in the repository inventory to queue collection for multiple repositories. Use Recompute… on the Productivity page to rebuild classifications and derived scores from imported PRs.

Configure agent readiness

1. Open Settings → Productivity → Agent readiness as an administrator.
2. Turn on Enable agent readiness scans to authorize repository context reads. Readiness starts disabled and works independently of productivity score enablement.
3. Expand a rule to edit its weight, repository selectors, paths, content pattern, or remediation. Add a custom rule for your documentation conventions. Enter paths relative to the repository root, one per line: docs/designs/*.md for direct children or docs/designs/**/*.md for nested documents. Use nirmata/aicontrols or nirmata/* as a repository selector, separately from the paths.
4. Optionally expand Preview path matching and enter example paths. Preview checks path matching and repository applicability only; it neither reads GitHub nor checks file content.
5. Select Save readiness settings. The server validates the paths and RE2 patterns before saving a version. Changed settings schedule new observations when enabled. Historical results keep their original rules.

Weights need not total 100. Each repository's enabled, applicable positive weights form its denominator. Disable a rule or set its weight to zero to exclude it. At least one enabled rule must have a positive weight. A matching file awards each rule's weight only once.

Restore default rules changes only your draft and preserves scan enablement; select Save readiness settings to apply it. Saving unchanged rules does not create a version. If another administrator saves first, your draft remains on screen. Select Load latest saved rules, review them, and choose Replace draft with saved rules before applying your edits again.

If a background refresh fails, the settings page warns that queue status may be out of date. Select Retry readiness settings to refresh it. Your unsaved rule edits stay in the form.

Inspect repository readiness

When a successful refresh finds a newer saved rules version, the page preserves your draft and pauses saving. Select Load latest saved rules, review the changes, and select Replace draft with saved rules before editing and saving against the new version. A queue-only refresh keeps your current draft editable.

Scores keep their fractional precision in the repository list and detail panel. For example, two passed points out of three applicable points display as 66.67/100. A complete score of 0/100 differs from an incomplete result, which has no numeric score.

1. Open Settings → Productivity → Repositories. The Agent readiness column loads summaries for the visible page. Repository search, sorting, and pagination retain their existing behavior.
2. Open a repository. The Agent readiness panel shows its current assessment, observation date, branch and commit, rules version, and passed/applicable weight. Expand a rule to inspect evidence, diagnostics, and remediation. Evidence links point to the assessed commit.
3. Select Scan readiness now to request a fresh observation. Queued, running, and retry states show separately from assessment results. The existing PR collection scan controls remain separate.
4. Select View readiness history for dated observations and their original rule definitions. Use Load older observations to continue through history. Rule-version changes are marked; unknown results have no numeric score.

A complete 0/100 means the applicable rules were checked and none passed. Not scanned, Incomplete, Disabled, and Needs access have different meanings. Stale or last-complete evidence retains its original date and does not become a fresh result when a new scan fails. Unable to load readiness means the summary request failed; Readiness unavailable means no summary was returned. Refresh the repository list to retry a failed read. Readiness is a preparation heuristic; it does not certify instruction quality, agent loading, or productivity gains.

Resolve agent readiness collection problems

Agent readiness has separate settings, scan jobs, and evidence history. Its admin API uses /api/v1/productivity/readiness; see the request, response, and status-code reference. It requires the GitHub delivery-attribution capability and administrator access, independently of productivity score settings. Enabling readiness does not change your GitHub credentials.

If the repository registry fails to initialize, readiness controls are hidden and readiness API requests return 503. You can still use the repository inventory and collection settings to investigate the failure.

Readiness scans are unavailable in demo mode, and Scan readiness now is disabled. Use path preview to inspect rule matching with sample paths without contacting GitHub.

1. Confirm that repository collection and agent readiness are enabled, the repository is onboarded, and its owner is allowed. A pending, skipped, or out-of-scope repository cannot be scanned.
2. For Needs access, verify the integration's access to the repository and its Contents read permission. Refresh inventory verification after correcting access, or request a new readiness scan. A GitHub 403 or 404 is not a missing-document result.
3. For an incomplete result, inspect the safe reason code and rule diagnostics. Unsupported binary, invalid UTF-8, Git LFS pointers, or oversized files cannot establish readiness. A different valid alternative can still satisfy a rule.
4. For a stale result, compare its scan time, configuration version, and branch with the current settings. Keep the last complete observation separate from the current incomplete attempt. Queued and retrying scans do not update old evidence timestamps.

A scan permits 100,000 tree entries, 64 MiB of expanded tree-path metadata, 200 provider HTTP attempts, 512 candidate blobs, 256 KiB decoded per blob, 16 MiB of decoded content, 16 MiB of path-resolution work, and five minutes. Reusing a cached symlink target and allocating its path components still consume the path-resolution budget. Committed symlinks can traverse at most eight links within the same repository; escapes, excluded paths, and submodules are rejected. Fixed exclusions cover .git, node_modules, vendor, dist, build, and coverage segments. A rule cannot override those exclusions.

Content checks also have a cumulative work budget. Rechecking cached files for different rules consumes that budget, including nonempty checks. Exhausting it produces an incomplete result with regex_budget and no numeric score.

Path preview allows at most 1 MiB of result text before JSON encoding. If a preview returns response_too_large, reduce the paths or rules in the request.

The queue accepts at most 1,000 outstanding scans per tenant. Queue count includes queued, running, and retrying jobs; oldest due time describes eligible repositories still waiting for a job to be admitted. Manual requests allow one new scan per repository every five minutes and 20 new scans per tenant per minute. Scheduled scans do not count against these manual limits. A request for already queued work returns the existing job. GitHub rate-limit responses, including typed GraphQL errors, pause collection for the affected integration or quota resource.

Requests deferred by a shared GitHub cooldown do not consume the scan’s HTTP request limit. Token exchanges, authentication retries, and redirects each count when sent. Transient provider failures receive at most three retries, with jittered 1-, 5-, and 15-minute delays and any longer valid provider backoff. Expired provider hints and deadlines more than 30 days ahead are ignored; collection uses the other valid hint or its normal retry delay. Access failures wait for access recovery or a manual retry, including when repository metadata is readable but a required file is denied. Worker restarts preserve the retry limit, even when a new scan replaces an assessment of an older branch. Resource-limit failures do not retry immediately.

API clients must send the current configuration version when saving settings or requesting a scan. On a version conflict, reload and review the current settings. For scan retries, reuse the same request key and parameters to receive the same job for up to 24 hours while the repository remains eligible. Disabling readiness or repository collection, offboarding the repository, or excluding it from scope also blocks replay of an accepted request. Respect Retry-After on admission limits. History pages include their referenced immutable configuration snapshots; do not label old observations using today's rules.

History pages can contain fewer items than requested to keep assessment data within 8 MiB and configuration snapshots within 2 MiB. Follow nextCursor to continue without skipping observations. If one assessment alone exceeds the assessment limit, the API returns 422 response_too_large instead of loading that record or silently advancing past it.

Detail responses also have an 8 MiB limit, including current and last-complete evidence and their configuration snapshots. An oversized detail response returns 422 response_too_large; compact repository summaries remain available.

Disabling the GitHub integration or changing its credentials stops further reads and publication by scans using the old credentials, even if you immediately restore the previous credential values. Changing readiness rules or repository identity during a retry wait schedules fresh work promptly, while still respecting shared GitHub rate limits.

Scans also limit repeated evidence and diagnostic text to 1 MiB before encoding, and published assessments to 8 MiB. Exceeding the evidence budget produces an incomplete evidence_limit result with no score. Oversized historical evidence is skipped for scan reuse; the worker collects fresh evidence instead.

Inspect AI ROI company evidence

AI ROI is available to administrators under Productivity → AI ROI when product storage is enabled (storage.enabled: true). Stateless deployments do not expose this workspace. The workspace uses your company’s collected PR data and the selected baseline. If the workspace is unavailable, the page reports that AI ROI is not enabled in this instance.

To browse references, open Productivity → Baselines and choose Industry & Research Baselines, Open Source Baselines, or My Company Baselines. These libraries display saved references without waiting for the company activity report. Creating a company baseline captures evidence for the scope and period you select in the builder.

1. Open Productivity → AI ROI and choose a reporting period and comparison baseline. The reporting period defaults to the last 30 complete days. Select View report to load company evidence. A loading indicator stays visible while the report is prepared; if loading fails, select Try again. After the report loads, apply repository and developer filters to focus the company evidence.
2. Read the evidence notice in the Estimated capacity multiplier card. It identifies the company data source, incomplete metadata, unresolved-author exclusions, and unavailable AI costs for this scope.
3. Expand Assumptions to inspect the baseline and company scenario. If collection needs attention, open Settings → Productivity → Repositories to manage repository connections and collection.

The detailed company collection preview is not currently displayed on the AI ROI page. The evidence notice remains visible while assumptions are collapsed.

Metadata readiness describes current scalar PR evidence for the selected period. Unknown contributor identities are counted separately and excluded from human output. Company output currently uses raw additions and additions capped at 1,000 per PR; it does not apply eligible-file scoring or revert adjustment. Live spend-based metrics require verified tenant Gateway cost evidence for the selected contributors and reporting period. Gaps in pricing or developer identity can make these metrics unavailable; missing spend is never treated as zero. Report generation is unavailable for live company reports.