Customer Documentation · Support · Privacy Policy · End User Terms · Security
Baseline Guard turns Jira evidence into clear, defensible project assessments and decision-ready reporting.
Instead of relying on subjective status updates or manually reconstructing project health from Jira, Baseline Guard evaluates available Jira evidence to help teams understand:
Baseline Guard is built for project leaders, delivery teams, PMOs, consultants, and organizations that need project reporting they can explain and defend.
After installing Baseline Guard, open Baseline Guard from the Apps section of Jira.
To generate an assessment:
Baseline Guard evaluates Jira information available to the current user and produces an evidence-backed project assessment.
Baseline Guard is read-only. Generating an assessment does not modify Jira issues or project data.
Baseline Guard evaluates available Jira evidence rather than simply repeating Jira status fields.
An assessment can return a supported project health status or explicitly withhold status:
BASELINE INCOMPLETE means at least one mandatory evidence prerequisite is proven deficient. The report names the failed condition and the Jira evidence behind it. NOT ASSESSABLE means required evidence cannot be verified, or the governance checks cannot support a defensible project health status.
Both outcomes withhold ON TRACK, AT RISK, and OFF TRACK. Review the established requirements, proven deficiencies, evidence gaps, and proposed Jira remediation. Full assessment readiness means status can be assessed; it does not mean the project is healthy.
NOT ASSESSABLE is an intentional safeguard.
Baseline Guard does not manufacture confidence when the underlying Jira evidence is incomplete.
When available evidence cannot support a defensible assessment, Baseline Guard identifies the deficiency so the team can understand what is missing and address it.
A missing answer is more useful than a confident answer unsupported by evidence.
A project assessment is only as reliable as the evidence supporting it.
Baseline Guard communicates evidence confidence to help users distinguish between a strongly supported assessment and one based on limited Jira information.
Where evidence is incomplete, Baseline Guard surfaces that limitation rather than silently filling the gap with assumptions.
This allows stakeholders to understand both the project assessment and the strength of the evidence behind it.
Evidence is central to Baseline Guard.
Important conclusions are tied to the Jira information supporting them so users can understand why an assessment was reached.
Baseline Guard distinguishes between:
This distinction helps stakeholders understand what Jira establishes directly and what represents evidence-based analysis.
Where source issues are presented, users can return to the underlying Jira issue for additional context.
Baseline Guard is designed to prevent unsupported Jira issues from being presented as evidence for a conclusion.
Baseline Guard supports several reporting periods for common project and delivery cadences.
Available reporting periods include:
The assessment is generated using Jira evidence available for the selected project and reporting period.
Executive reporting is designed to answer the questions leadership needs answered without requiring executives to interpret Jira workflow details.
Executive reporting emphasizes:
Routine ticket activity and unnecessary workflow detail are minimized.
The goal is a concise, decision-ready view of the project rather than another Jira activity report.
Baseline Guard turns Jira evidence into clear, client-ready project reporting.
Client reporting focuses on information appropriate for external stakeholders, including:
Client reports are designed to communicate project reality without requiring clients to understand internal Jira workflows.
Internal operational information that is not appropriate for a client audience is excluded from the client reporting context.
This includes internal details such as assignees, labels, sprint names, priority levels, internal dependencies, and internal-only risks.
Internal reporting gives delivery teams a detailed, evidence-backed view of project health.
Internal reporting can surface:
When Baseline Guard cannot produce a defensible assessment, internal reporting helps explain what evidence is missing and what the team needs to address.
This makes a NOT ASSESSABLE result actionable rather than simply reporting that information is unavailable.
Baseline Guard identifies meaningful delivery signals supported by available Jira evidence.
Depending on the project and evidence available, an assessment may surface:
Baseline Guard is designed to prioritize meaningful project signals rather than reproduce every Jira issue in a status report.
When available Jira evidence indicates that a decision may be required, Baseline Guard can surface that decision for attention.
Depending on the evidence available, a decision item may include:
Baseline Guard does not manufacture a decision when the Jira evidence does not support one.
Where supported by the evidence, Baseline Guard may identify recommendations, proposed actions, or remediation.
Recommendations are presented as recommendations rather than established facts.
This distinction is intentional.
Baseline Guard separates:
What the Jira evidence establishes
from
What may be an appropriate response to that evidence
This helps teams use Baseline Guard for decision support without presenting proposed actions as facts.
Missing information can itself be an important project signal.
Baseline Guard is deliberately conservative when Jira does not contain enough information to support a conclusion.
Instead of inventing missing facts or presenting unsupported certainty, Baseline Guard identifies relevant evidence deficiencies and explains their effect on the assessment.
Insufficient evidence may result in a NOT ASSESSABLE determination.
The principle is simple:
No evidence, no invented certainty.
Baseline Guard is designed around least-privilege access.
The app uses Jira’s read:jira-work permission to read project and issue information required to generate assessments and reports.
Baseline Guard:
read:jira-user scope.Jira requests are made in the context of the current user.
Baseline Guard cannot be used to access Jira project or issue information that the current Jira user is not permitted to access.
Depending on the project, reporting period, and reporting audience, Baseline Guard may evaluate Jira information including:
Baseline Guard requests the Jira fields required for assessment rather than requesting all available issue fields.
Jira comments are not fetched or used as assessment evidence.
Information included in the generated report can vary according to the selected reporting audience.
Current report generation runs within Atlassian Forge and uses deterministic baseline checks, governance rules, and audience report assembly. It does not use an LLM to generate the current project status or report content.
Executive, Client, and Internal reports use the same Jira facts and authoritative determination, with presentation appropriate to the selected audience. Facts, interpretations, and proposed actions are distinguished. The app does not invent owners, dates, dependencies, impacts, or consequences that Jira does not establish.
The app does not require external AI API keys or send Jira issue data to an external AI provider operated by Baseline Guard.
Baseline Guard assessments are generated on demand from Jira data.
Baseline Guard does not operate an independently hosted or externally managed customer-data store. During assessment generation, Jira information is processed by the Forge app, and a generation/assessment record may be stored in Atlassian-hosted Forge Key-Value Store (KVS).
Depending on the job state, that record may include the requestor’s Atlassian account ID; Jira project key and name; selected reporting period and audience; job status and timestamps; validated assessment and evidence-derived fields; deterministic baseline, governance, and provenance information; or structured error information.
Active QUEUED and RUNNING records receive a one-hour time-to-live when written. Terminal records, including completed, failed, and non-assessable records, receive a seven-day time-to-live when written. The applicable time-to-live is applied again when a record is updated, and records may be deleted sooner through the app’s personal-data reporting process.
Generated assessment content is not written back to Jira.
Local interactions or edits to a generated report are page-local and are not persisted by Baseline Guard.
Generating a new assessment evaluates the Jira evidence available at the time of generation.
Baseline Guard does not intentionally log Jira issue content.
For complete information about data handling, processing, and privacy, see the Baseline Guard Privacy Policy.
Baseline Guard is an assessment and reporting layer for Jira.
Generating or reviewing an assessment does not change:
Baseline Guard does not become another project system of record.
Jira remains the source of project evidence.
Baseline Guard can only evaluate evidence available in Jira and accessible to the current user.
The quality and completeness of an assessment therefore depend on the quality and completeness of the underlying Jira data.
Missing, outdated, or incomplete Jira information may:
Baseline Guard surfaces known evidence limitations where appropriate rather than treating incomplete information as complete.
Confirm that your Jira account has access to the projects you expect to assess.
Baseline Guard respects the permissions of the Jira user accessing the app.
This is not necessarily an application error.
A NOT ASSESSABLE result means the available Jira evidence does not support a sufficiently defensible assessment.
Review the evidence gaps or remediation information presented by Baseline Guard to determine what Jira information needs attention.
Baseline Guard can only evaluate evidence available in Jira and accessible to the current user.
Incomplete Jira records or a reporting period containing limited activity may therefore produce a more limited assessment.
Confirm that the information exists in Jira, falls within the selected reporting context, and is visible to your Jira account.
The selected reporting audience can also affect which information is included.
Client reports intentionally exclude certain internal operational details.
Baseline Guard assessments reflect Jira evidence available when the assessment is generated.
If project information has changed, generate a new assessment to evaluate the current Jira evidence.
Try generating the assessment again.
If the problem continues, contact Baseline Guard Support with a description of the problem and any error message displayed by the application.
Please do not send confidential Jira issue content through an unapproved support channel.
Baseline Guard is built on Atlassian Forge and designed to minimize unnecessary access to customer information.
The product is designed around the following principles:
For complete information about data handling, processing, and privacy, see the Baseline Guard Privacy Policy.
Baseline Guard is a supported commercial Atlassian Marketplace application.
For installation issues, assessment-generation problems, or questions about using Baseline Guard, contact Baseline Guard Support.
When contacting support, include:
Please do not send confidential Jira issue content unless specifically requested through an approved support channel.