Frequently Asked Questions

Omniboard is built for tech leads, lead architects, platform teams, and lead engineers who need to coordinate migrations, standards, dependency cleanup, ownership metadata, or security checks across many independently owned repositories.

Code search helps answer one question at one moment. Static analysis usually focuses on local code quality. Omniboard is built for cross-repository engineering initiatives. Teams can define a check, run it across projects, connect results to ownership, track adoption over time, and verify whether the original finding was resolved.

Good first use cases are concrete, repeated across many projects, and painful enough that teams already care about them: dependency cleanup, framework migration, deprecated API removal, required config adoption, ownership metadata, security checks, or exception burn-down.

No. Most teams start with one initiative, one project group, or one set of checks. The analyzer can run where it is useful first, then expand as the initiative proves value and more teams want current results.

Checks can be scoped by project group, file path, matching strategy, and extracted metadata. Leads can start with narrow, observable signals, test checks in the playground, and expand only when the result is trustworthy enough to drive action.

Yes. Omniboard can connect findings to project metadata, teams, groups, and ownership views. This helps platform teams and lead architects route follow-up work to the right teams instead of manually mapping repositories to owners.

The analyzer can run on demand from a local workspace or as part of CI/CD. CI integration keeps results current without manual status collection, which is especially useful for migrations, standards, dependency updates, and exception burn-down.

Yes. Dashboards and result views can show adoption progress, remaining gaps, unchecked projects, and exceptions over time. This gives leads a live view for architecture reviews, migration steering, and leadership updates.

Not every project can move at the same time. Omniboard helps teams separate passing projects, failing projects, unchecked projects, and known exceptions so leads can review risk and burn exceptions down intentionally.

Projects without fresh analyzer results can be treated separately from passing or failing projects. That distinction is useful because "not checked yet" is a different problem than "checked and still needs work."

Checks are usually defined by the people who own the standard or initiative: lead architects, platform teams, library owners, security teams, or tech leads. Product teams then consume the results that apply to their projects.

Omniboard helps teams find affected projects, group them by team, version, usage pattern, or blocker, and track movement until the old path can be removed. The goal is to replace spreadsheet status with checks from real project data.

Omniboard gives agents scoped work, not broad authority. Through the MCP integration, an agent can retrieve the finding for the current project, the relevant context, and the instructions needed to make a focused change. The analyzer can then validate whether the check is resolved.

In Omniboard, a project usually maps to a repository. The @omniboard/analyzer looks for project definition files such as package.json or pom.xml and uses the definition closest to the repository root as the main project identifier. Nested definitions are stored as sub-projects.

Omniboard is primarily designed for polyrepo environments, but repositories can contain multiple projects.

Omniboard supports repositories that contain multiple projects, but it is primarily designed for polyrepo environments. If your organization has one very large monorepo, Omniboard may be less useful because many views are centered around the project/repository model. If your repositories contain multiple apps, packages, or services, the analyzer can still capture nested project definitions as sub-projects.

Yes. Omniboard supports backend projects, including Maven-based projects where pom.xml is used to resolve the project identity.

No. Many useful checks are simple file, dependency, or content matches. For advanced cases, regex and XPath make checks more expressive, and the integrated playground helps test them before running the analyzer against real projects.

No. The @omniboard/analyzer runs in your project workspace and uploads check results, not your source code. Results can include matched values or extracted metadata depending on how checks are configured, so organizations should define checks according to their internal data policy.

Payload limits can be configured in organization settings to control how much data can be stored per check and per project.

Omniboard runs and stores its data in Zurich, Switzerland on Google Cloud Platform, Europe West 6.

Omniboard supports Microsoft Entra ID / Azure enterprise application integration. Organizations can assign user groups to control access and roles. Custom SSO setups can be discussed case by case.

Please get in touch to learn more.

Please get in touch if you did not find an answer to your question.