Project Boundary

Scope determines how an action is distributed. A project-scoped action is performed once, centrally — for example, submitting the project-wide stormwater plan. A component-scoped action is performed independently at every applicable component — for example, installing exclusion fencing at each of 20 construction areas.

A Tenant is the organization a Beacon workspace belongs to. Beacon is multi-tenant: each tenant’s projects, documents, users, and configuration are isolated from every other tenant’s, and a user operates within a single tenant at a time.

Tenant-level settings — display labels, enabled features, notification defaults, and user roles — apply uniformly across every project the tenant owns.

A Work Area is a subdivision of a component, used when field tracking requires finer grain than the component itself provides. Work areas form the most granular level of the Project → Component → Work Area scope hierarchy.

Evidence of Compliance and monitoring records can be scoped to a work area, isolating activity to a specific portion of a component.

Beacon turns a body of regulatory documents into a working compliance program. Everything in the app follows one flow: documents are cataloged, obligations are planned into actions, and completed work is proven with evidence.

1. The Data Catalog holds source documents and the commitments and requirements extracted from them.
2. Tracking is where planned actions become day-to-day work, tracked per project or per component.
3. Monitoring captures what happens in the field — daily reports, observations, and surveys.
4. Reporting assembles evidence of compliance into the reports agencies expect.

Search reads the full text of everything in a project — including the body text of commitments and uploaded documents, not just titles.

1. Press / on any page, or click the search field in the top bar.
2. Type a few words. Results group by type — commitments, requirements, actions, documents — with matching snippets highlighted.
3. Press Enter on a result to open it, or choose “See all results” for the full page with filters.

An Implementation is the tracked execution of an action: its status, assignee, tasks, comments, and evidence. The action defines what must be done; the implementation records doing it. In daily use, implementations are what teams refer to as the actions.

The number of implementations an action generates is determined by its scope and frequency. A one-time, project-scoped submission generates one implementation. A recurring, component-scoped inspection generates one per component, per occurrence.

A Component is a discrete location or work package within a project — a launch shaft, an intake site, a construction segment. Components exist because the same obligation frequently applies independently at each location.

A component maps to the commitments that apply to it, may carry its own milestone dates, and receives its own implementations of component-scoped actions. A Work Area subdivides a component further when field tracking requires finer grain.

A Permit is an authorization or approval a project must secure from a regulatory agency before or during construction. Beacon tracks each permit through its acquisition pipeline — from not yet applied, through agency review, to issued.

An issued permit typically becomes a source document: its conditions are extracted as commitments and enter the catalog alongside every other obligation.

Permit Tracking lists every permit and approval a project needs, each with its current status in the acquisition pipeline — from not yet applied, through agency review, to issued.

1. Each row is one permit; the status lozenge shows where it sits in the pipeline.
2. The date column shows the next deadline — a submittal window, an agency response due, or an expiration to renew.
3. Open a permit to see its conditions, responsible contacts, and the source document it will become once issued.

A project may have dozens of components, though most people work in a few. Starring pins a component to the project dashboard as a card showing its Tracking, Monitoring, and Reporting pulse — the entry point into that component’s own dashboard.

1. Star a component from the all-components list, or from the star in its own header.
2. Starred components appear on the project dashboard in the Components section, below the project-wide row.
3. Un-star from either place; the component itself is unaffected.

Stars are yours alone — starring a component does not change what anyone else sees. The Components section always leads with a project-wide row for actions that belong to the project rather than to any one component.

Everything urgent on the dashboard is an action with a due date. Each action belongs to one of the three zones by its type — tracking, monitoring, or reporting — so a lapsed survey is a monitoring action and an agency submittal is a reporting action. There is no separate list of critical items to maintain.

The Tracking, Monitoring, and Reporting modules each count their own overdue actions and the ones due within the next fourteen days, then list the most urgent of them. Red means past due; amber means due soon. Clicking any of them opens the action itself.

An action leaves the surface when it is completed or its due date moves. There is nothing to configure — the modules read the same action records you work with in each zone.

The timeline across the top of the dashboard plots three things on one date axis: action due dates, season windows, and project milestones. It opens a week before today so anything already overdue stays in view.

1. Switch the window between 30, 60, and 90 days to look further ahead.
2. Click any mark — a dot, a season bar, or a milestone — to pin its details open.
3. Seasons show the ones starting or ending inside the window first; use “Show all” when a project carries many.

Action dots follow the same colors as the modules: red for past due, amber for due soon, gray for later. Milestones are shown in blue because they mark schedule rather than urgency.

A Daily Monitoring Report (DMR) documents one day of field monitoring: the observer, site and weather conditions, construction activities underway, recorded observations, photographs, and narrative notes.

DMRs connect field activity to compliance. When an obligation requires daily biological monitoring during construction, the DMRs documenting that monitoring constitute the evidence the obligation was met.

An Observation is a single recorded field event: two burrowing owls at the north staging area, an intact silt fence along the eastern boundary, or wind exceeding 25 mph with dust control activated. An observation typically belongs to a DMR and carries species data, location, time, and photographs.

A Survey is a structured field record — typically a species or habitat survey — collected in a field application such as Fulcrum or Survey123 and synced into Beacon. Surveys supply the dated evidence behind clearances and compliance countdowns.

A survey record does not affect compliance until it passes quality-control review. Pending records are excluded from clearance and evidence calculations by default.

Site Clearance is the determination of whether a specific site is clear to disturb ground on a given day. Beacon detects potential blocks — a lapsed nesting survey, an open wildlife buffer — and marks the site provisionally blocked until a qualified reviewer records a decision.

Detections are advisory; reviews are authoritative. A site is clear only when no unresolved block remains and the governing reviews permit disturbance.

The Monitoring Portal is the area of Beacon that reports commitment-level compliance against field activity. It identifies commitments that are out of compliance and the observations driving each result, matched by species and condition.

The portal reads the same observation and survey records captured elsewhere in Monitoring; it holds no separate data of its own.

Survey records flow in from field collection tools such as Fulcrum and Survey123. Before a record affects compliance — clearances, countdowns, evidence — it passes a quality-control review.

1. New records arrive with a pending-QC status in the Surveys grid.
2. A reviewer checks species identification, coordinates, and required fields, then approves or returns the record.
3. Views default to QC-approved records; toggle the filter to see pending ones.

Site Clearance answers one question per site: is it clear to disturb ground today? The system detects potential blocks — a lapsed nesting survey, an open wildlife buffer — and marks the site provisionally blocked until a qualified reviewer decides.

1. Green sites are clear; amber sites carry a provisional block awaiting review; red sites are blocked by a recorded decision.
2. Open a site to see each discipline’s reviews, the detections behind them, and the required outcome.
3. Reviews overrule detections: the system detects, a reviewer decides.

Evidence of Compliance is the terminal output of the compliance flow: the report, photograph, receipt, signed form, or monitoring record that proves an obligation was satisfied. It is the material presented to a regulatory agency during an audit.

Evidence attaches to action implementations and may also link to checklist items that satisfy specific requirements per component. Field-sourced evidence can derive directly from Daily Monitoring Reports.

A compliance report presents the evidence behind a set of obligations in the format an agency expects. Reports are assembled from existing Evidence of Compliance records; they create no new evidence.

1. Open Reporting and choose the report template that matches the agency’s required format.
2. Select the scope — project, component, or work area — and the reporting period.
3. Beacon gathers the evidence records in scope; review the set and exclude any records that do not apply.
4. Generate the package. The output lists each obligation, its status, and the linked evidence.

A Source Document is a regulatory record attached to a project: a permit, an environmental impact report, an incidental take permit, a contract, or an agency agreement. Every obligation in Beacon originates from a source document.

A project may carry dozens of source documents from multiple agencies, and a single source may contain anywhere from a few to several hundred discrete obligations. Uploading the original file makes its text available for search and assisted commitment extraction.

A Commitment is a single obligation a project must satisfy, captured in the regulatory language of its source document. Each commitment carries structured attributes — type, resource category, phase, species, and season — that support filtering and planning.

The same real-world obligation frequently appears across multiple documents. Each appearance is retained as a separate commitment; the overlap is resolved downstream, when requirements are consolidated into actions.

A Requirement is one discrete unit of work contained within a commitment. A commitment stating “prior to grading, conduct protocol-level surveys for burrowing owl and submit results within 30 days” resolves to two requirements: conduct the survey, and submit the results.

Each requirement carries its own type, scope, and frequency. The requirement is the unit consolidated into trackable actions.

An Action is a planned unit of compliance work. It consolidates requirements — often drawn from many commitments — that describe the same underlying task. A requirement to submit the stormwater plan appearing across 44 commitments resolves to one action.

Each action defines the work, the expected evidence, the schedule, and the responsible party. Actions begin as drafts and must be published before they generate trackable implementations.

Every requirement keeps its full ancestry: the commitment it came from, and the source document that commitment was extracted from. This is how a requirement is traced to the exact regulatory language behind it.

1. Open the requirement. The lineage strip at the top shows Source → Commitment → Requirement.
2. Click the commitment to read the obligation in the document’s original words.
3. Click the source to see the document’s details, agency, and attached file — with the cited passage highlighted.

A Feature Flag is a configuration switch that turns a Beacon capability on or off for a tenant. Flags allow a feature to be released to specific tenants independently, without a code change.

Feature flags are administered in tenant settings. A disabled flag hides its feature from navigation and removes its surfaces from every project the tenant owns.

Tenant settings control behavior shared across every project a tenant owns: display labels for core entities, default notification rules, enabled features, and the user roster. Changes apply tenant-wide.

1. Open Settings and select the tenant settings section (available to tenant administrators).
2. Adjust display labels, defaults, or enabled features; each change is scoped to the current tenant only.
3. Save. Tenant-wide changes take effect on the next page load for every user in the tenant.

Access in Beacon is governed by role. A role determines which zones a user can view and which records a user can create, edit, or approve. Users are added at the tenant level and assigned one or more roles.

1. Open Settings and select Users.
2. Invite a user by email, or select an existing user to change their assignment.
3. Assign roles — for example, viewer, contributor, or reviewer — and save.

Notifications alert users to compliance events — an approaching deadline, a new provisional block, a returned survey. Defaults are set at the tenant level; each user may adjust their own delivery preferences within those defaults.

1. Open Settings and select Notifications to review the tenant’s default rules.
2. Enable or disable notifications by event type, and set the delivery channel for each.
3. Individual users adjust their personal preferences from the same section; tenant defaults apply where a user has made no choice.