User Feedback & Support System
Integrated feedback and support system for bug reports, feature requests, and customer assistance
Overview
The Feedback System has two distinct purposes: in-form field-level feedback that directly improves AI fill accuracy for a specific form, and general bug/feature feedback routed to internal tracking.
In-form feedback lets users flag individual filled fields as correct or incorrect during a fill session. When a user submits a correction for a field, that correction is saved as an example tied to the field's hash. On subsequent fill sessions for the same form, the saved corrections are passed as examples to the AI, which uses them to improve fill accuracy for that specific field. This mechanism is scoped to the workspace — corrections made in one workspace do not affect fill results in any other workspace.
Bug reports and feature requests are submitted via the in-app feedback widget and routed to the internal issue tracking system. These do not feed into the AI fill pipeline.
Key Capabilities
- In-Form Field Flagging: Users flag individual filled fields as correct or incorrect during a fill session
- Correction as Example: Field corrections are saved as field-level examples tied to the field's hash within the workspace
- Example-Driven Fill Model: Saved corrections are passed to the AI as examples in subsequent sessions on the same form — the model receives known-correct values before generating its output
- Workspace-Scoped Accuracy Improvement: Corrections improve accuracy for the specific form within the workspace; they do not cross to other workspaces or users
- Bug Reporting: Submit bug reports with context via the in-app widget; routed to internal tracking
- Feature Requests: Submit feature suggestions; routed to internal tracking
How It Works
In-Form Field Feedback
During or after a fill session, users can review the AI-filled values for each field and flag them as correct or incorrect. When a field is flagged incorrect and the user provides the correct value, the correction is stored as an example for that field. Examples are linked by a field hash that identifies the specific field within a specific form, within the workspace.
On the next fill session for the same form in the same workspace, the system retrieves any saved examples for each field and passes them to the AI. The example-driven AI path uses the examples to bias the fill result toward the previously confirmed correct values. If a field has no saved examples, the standard fill model is used instead.
Over time, repeated corrections accumulate as examples, progressively narrowing the variation in AI output for fields where the correct value is consistent (for example, a company name field that should always be filled the same way). Fields where the correct answer varies per session (for example, a date field) benefit less from this mechanism, since examples from prior sessions may not reflect the current session's correct value.
Bug Report Flow
User Process:
- Open the feedback widget (accessible from any page)
- Select "Report a Bug"
- Describe the issue, expected behavior, and actual behavior
- Optionally attach a screenshot
- Submit
The report is routed to the internal tracking system with the user's workspace and session context. The feedback widget does not pass form field values in bug reports to avoid exposing sensitive document content.
Feature Request Flow
User Process:
- Open the feedback widget
- Select "Request a Feature"
- Describe the feature and the use case it would address
- Submit
Feature requests are routed to internal tracking. Requests are reviewed during product planning cycles. This channel does not feed into the AI fill pipeline.
Use Cases
In-form field feedback is most valuable for organizations that fill the same form repeatedly with consistent expected values. A workspace that fills a vendor onboarding form hundreds of times can use corrections to lock in accurate fill behavior for fields like "Vendor Type" or "Payment Terms" that have predictable values. After a few sessions with corrections applied, the AI consistently produces the correct values for those fields without requiring manual review on every session.
Bug reporting is used to surface integration or rendering issues — for example, a field that renders at the wrong position due to a page rotation edge case, or a session that fails to complete for a specific PDF structure. These reports reach the engineering team with enough context to reproduce and fix the issue.
Benefits
- Corrections Improve Future Sessions: Field-level corrections become examples passed directly to the AI — the improvement applies on the next session, not after a long retraining cycle
- Accuracy Improvement Is Form-Specific: The field-hash linking ensures examples apply only to the field and form where the correction was made, not to unrelated fields on other forms
- Workspace Isolation: Corrections and examples are workspace-scoped; a correction made in one workspace does not affect fill results in any other workspace
- Efficient Example-Driven Model: Example-driven fills use a lower-effort AI path than full-inference fills, making them faster and lower-cost while still incorporating correction history
- Bug Reports Reach Engineering with Context: Reports include workspace and session context, reducing the back-and-forth needed to reproduce issues
Security & Privacy
All data is workspace-scoped and protected by JWT authentication middleware across all service layers. Field-level correction examples are stored and retrieved only within the workspace where they were created — they are never shared across workspaces or visible to other users. Bug and feature feedback is routed to internal tracking and is not exposed publicly. Form field values are not included in bug reports submitted via the feedback widget.
Common Questions
How quickly do corrections affect fill accuracy?
Corrections take effect on the next fill session for the same form in the same workspace. There is no retraining cycle or delay — saved corrections are retrieved at the start of each session and passed as examples to the AI. If a field has saved examples from prior corrections, the model receives those examples and uses them to bias its output toward the historically correct values. If a field has no saved examples, the standard fill model is used with no change in behavior.
How does example-driven filling differ from the standard fill model?
Fields with saved correction examples use a dedicated AI path configured at reduced reasoning effort. This is distinct from the standard fill path, which does not receive prior correction examples. The reduced effort setting makes example-driven fills faster and lower-cost per field. The tradeoff is that the model relies more heavily on the provided examples to produce accurate output — which is appropriate when the examples are known-correct corrections from prior sessions. For fields where no examples exist, the standard fill model is used.
Do corrections from one workspace affect other workspaces?
No. Correction examples are linked by field hash within a specific workspace. Examples saved in one workspace are never retrieved or applied in another workspace. A correction made by one organization's workspace does not affect fill results for any other organization's workspace, even if both workspaces fill the same form template.
What happens if I submit an incorrect correction?
Saved examples persist and are passed to the AI in subsequent sessions. If an incorrect correction is saved as an example, it will bias future fills toward the wrong value. To address this, review the saved examples for a field and remove the incorrect entry. Once the incorrect example is removed, subsequent sessions will no longer receive it as an input, and the model will revert to its standard fill behavior for that field (or to the remaining correct examples, if others exist).
How is bug and feature feedback handled?
Bug reports and feature requests submitted via the feedback widget are routed to the internal issue tracking system. They are not processed by the AI fill pipeline and do not affect fill accuracy or model behavior. Bug reports include workspace and session context to help engineering reproduce the issue. Feature requests are reviewed during product planning cycles. Neither type of feedback is shared publicly or cross-workspace.