> For the complete documentation index, see [llms.txt](https://docs.output.industries/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.output.industries/technical-onboarding/release-notes/2026/week-32-or-2026.md).
# Week 32 | 2026
**Granular control, downtime accountability, and faster analysis**
This release introduces per-station feature configuration, mandatory downtime notes, and significant performance improvements across analysis pages.
### New Features
**Quality Analysis**
Bad production can now carry a quality reason, giving visibility into why units were rejected. A new quality reason type sits alongside downtime and non-production in the existing reasons admin.
* Quality Analysis page — reason-breadcrumb drill-down with Bad Count and Cost columns, SKU filter, and CSV export. Mirrors the Downtime Analysis layout.
* Tablet — optional quality-reason picker when an operator enters bad quantity.
* Signals — bad\_production\_reason field applies to the bad count in the same message.
* Production Entries — new Bad Quality column-group toggle showing the reason per row, plus a Bad Reason column in the CSV export.
**Granular feature configuration**
Features like manual production, manual downtime, production correction, and schedule flexibility can now be configured independently at the **plant, station group, or station level** — not just account-wide. A station inherits its plant's setting unless overridden, giving you precise control over which capabilities are available where.
**What this means in practice:** you could enable manual downtime for one production line while keeping it off for the rest of the plant, without affecting any other feature.
**Mandatory downtime notes**
Downtime reasons can now be flagged to **require a note**. When an operator assigns that reason — on the tablet, on the web, or via the SDK — they must provide a free-text explanation before the assignment is accepted. Notes appear on the Downtime List, in the detail view, and in CSV exports.
**Task availability windows**
Cron-based Tasks gain an **"Available Before Deadline"** setting. Instead of appearing for the entire period between fires, a Task now only shows on the tablet once the lead time begins — reducing clutter and directing operator attention to Tasks that are actually due.
**Station Notes history on the tablet**
Tapping the note in the station header now opens a **history of the last 5 notes**, giving operators quick context on what's happened at the station without leaving the production screen. The "Add Note" button works as before.
**Long-range date searches**
**3-month, 6-month, and 12-month** relative date ranges are now available across OEE, Trend, Hierarchy Explorer, Production views, Cycle Time Analysis, and Downtime Analysis. Combined with the performance improvements in this release, you can now analyse up to a full year of data directly within Busroot — making it far easier to spot seasonal patterns, long-term trends, and year-on-year comparisons.
### Improvements
**Energy metering support**
Plant- and group-level energy meters can now be modelled as dedicated meter stations, with energy computed automatically and kept separate from production views.
**Cycle Time Analysis loads up to 24× faster**
Queries that identify which stations ran a given SKU over a year now resolve in under a second, down from around 12 seconds. The detail page also carries your filters forward when drilling in, so you no longer lose your selection.
**Faster Weekly Report**
The Weekly Report now loads each tab on demand and fetches station and SKU data in single requests, noticeably reducing page load times on accounts with many stations.
**Persistent data cache**
Aggregated station data is now cached durably across deploys and server restarts. Previously, wide-range queries (e.g. a full quarter) could be slow after a deploy while the cache rebuilt. That penalty is now eliminated — cached results survive and are shared across all servers.
**Long reason descriptions no longer break tables**
Downtime and OEE Analysis tables now truncate over-long reason descriptions so the numeric columns stay visible and aligned, regardless of reason name length.
**Tasks wording and admin**
"Outstanding" tasks are now labelled **"Pending"** on the tablet and Cockpit. The manifest editor now shows all account settings with their defaults, making it easier to discover and toggle options.
### Bug fixes
**Cycle Time spec and parts-per-cycle**
The Cycle Time spec value now correctly accounts for parts-per-cycle, and production rows with no PPC configured are no longer incorrectly excluded from analysis.
**Trend and Pulse chart alignment**
Daily and weekly time windows on Trend and Pulse views now align correctly with your plant's production day and week boundaries, rather than snapping to UTC midnight. The week-aggregation tooltip also no longer cuts off data.
**Filters applying before you press Apply**
The metric and reason dropdowns on the Trend Viewer, and the status filter on Task History, now correctly wait for the Apply button instead of triggering immediately when changed.
**Schedule upload preview**
Fixed duplicate columns and incorrect row striping in the spreadsheet upload preview when importing schedules.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.output.industries/technical-onboarding/release-notes/2026/week-32-or-2026.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.