What data for this category looks like
Normally, data for text annotation projects covers daily work documents for annotation teams, NLP algorithm teams, and quality inspectors. This includes annotation specifications, sample packages, quality inspection reports, and problem feedback forms. Data sources mainly include proprietary corpus provided by customers, annotation results produced by annotation platforms, industry general vocabularies, and quality inspection sampling results. Data update frequency is mostly daily or synchronized per annotation batch. Core focus is on annotation logic for semantic boundaries, entities, and intents, which has a clear difference from visual feature annotation for image annotation projects.
How these characteristics impose constraints on permission and data isolation
The data characteristics of text annotation projects directly determine the constraint requirements for permission isolation. Multiple sources of customer proprietary corpus require strict division into access scopes per project or team to avoid cross-customer data leaks. Real-time permission verification applies to frequently updated sample packages and quality inspection reports to prevent unauthorized users from accessing the latest annotation results. Internal process documents such as annotation specifications involve project-specific logic, and access remains restricted to only core project members. Semantic annotation results contain customer proprietary information, and precise permission matching uses identifiers such as teamId and tmbId to prevent unauthorized access.
How to configure settings
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
teamId | Unique team identifier bound to the annotation project | Divide data access scopes by organizational structure, matching the permission hierarchy of annotation teams |
tmbId | Unique sample identifier generated per annotation batch | Isolate annotation samples from different batches to avoid cross-batch data confusion |
| Team role permissions | Assign permissions by role: Annotators only access assigned samples, quality inspectors access quality inspection data for their assigned batches, and administrators access full project data | Match permission division in annotation workflows, preventing unauthorized operations |
| Historical version field completion | Complete missing tmbId fields with the identifier of the corresponding batch | Fix permission failure issues caused by missing tmbId in historical documents prior to FastGPT v4.17.0 |
| Sensitive document access restriction | Only project administrators can view annotation specifications and quality inspection reports | Protect the confidentiality of internal process documents, preventing non-core personnel from accessing proprietary annotation logic |
| Bulk access threshold | Maximum 1000 samples per bulk access request | Control the processing volume of permission verification, avoiding service overload |
Three common configuration mistakes
- Issue: Some historical version annotation documents cannot be accessed by authorized members, and an "insufficient permissions" prompt appears on the interface. Cause: Early versions of application historical data did not write the
tmbIdfield, causing permission verification to fail to match the team identifier of the corresponding project. - Issue: Internal ticket system logs deployed on the intranet show MySQL connection refusals, while the MySQL service status is normal. Cause: Correct network isolation rules were not configured, causing internal services of the annotation project to fail to access the specified database instance.
- Issue: After generating a publicly accessible link, chat records and annotation discussion content from different users are visible to each other. Cause: Public links were not generated with the project-bound
teamId, causing session data to not be divided into the isolated space of the corresponding project.
How to confirm correct configuration
- View the details of any historical version annotation document, confirm that both the
teamIdandtmbIdfields exist and match the unique identifier of the current project. - Log in to the system with an annotator role, attempt to access an unassigned sample package, and confirm that access is denied with an insufficient permissions prompt.
- Generate a publicly accessible link, use two different accounts to initiate conversations and view data respectively, and confirm that their respective session contents do not interfere with each other.
- In an intranet deployment environment, test the database connection of the internal ticket system, confirm that the connection is normal and there are no permission error messages.
The values provided here are common starting points, and should be evaluated against the reader's own samples.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-10-19.