Feedback is the primary way you shape what a board shows and how it looks. You write it in plain language, and the system handles the rest.
What counts as actionable feedback
Layout and design
"Move the risk section to the top", "Make the phase timeline larger", "Replace the bar chart with a table", "Add a filter for workstream."
Data corrections
"The completion rate for Finance is showing 40% but it should be 62%", "The budget figure is stale, it was updated last week."
New content
"Add a section for OCM readiness", "Include a chart showing ticket volume by sprint", "Show which milestones have passed."
Commentary updates
"Update the executive summary to reflect the go-live decision made on Tuesday", "The commentary should mention the new integration risk."
What happens after you submit feedback
The system classifies your feedback: is it actionable, and what kind of change does it require?
If actionable, the board spec is updated to reflect your request.
Only the affected parts of the board are regenerated. Unrelated sections are left alone.
The feedback status is updated to 'Completed' once the change is live.
If your request cannot be fulfilled (for example, the data needed does not exist), the status is set to In Review and you are notified.
Version history
Every change to a board creates a new version. You can browse a board's history to see how it has evolved, compare versions, or understand what changed after a specific update.
Data versions
Created when new data is fetched and merged into the board. The underlying dataset changed: new tickets, new transcripts, updated metrics.
Visual versions
Created when a feedback-driven design or layout edit is applied. The data stayed the same; the presentation changed.
To view a previous version, open the board and access the version history panel. Each version is timestamped and labeled with the type of change made. You can restore any previous version if a recent change introduced something undesirable.
Boards are designed to reduce the effort of staying informed. They read your project data so you don't have to, surface what matters, and update when things change. The more you interact with them through feedback, refresh requests, and grounding rules, the more accurately they reflect how your team actually works.