Batch and lot attributes
Define typed category-specific lot fields and retain immutable approved value revisions for batches already present in authorised custody history.
Screen orientation
Field definitions and values are filtered by tenant, assigned site, item/field classification and lot-attribute permissions. Definition and value approval are independent maker-checker decisions.
Definition controls govern the reusable field first. The scoped batch register then supports visible-field search, CSV export and immutable capture or correction of values for one batch.
Field reference
The entries below describe the current screen controls and read-only values. They do not relax server-side validation, site scope, classification handling or required independence in a governed decision.
| Field or value | Control | Required or shown when | How to use or read it | Result |
|---|---|---|---|---|
| Item category | Select | Required for a field definition. | Choose the category whose batches need this attribute; do not create a tenant-wide field when the evidence is category-specific. | Scopes the field to qualifying items and batches. |
| Stable field key | Text | Required; unique within the category. | Use a durable machine-oriented key such as MANUFACTURER_HEAT. The key should not change when the operator label is clarified. | Provides stable search and snapshot identity. |
| Operator label | Text | Required. | Use the exact business wording operators recognise on certificates or material markings. | Becomes the user-facing field name. |
| Data type | Select | Required. | Choose TEXT, NUMBER, BOOLEAN, DATE or ENUM according to the real evidence; do not encode multiple facts into free text. | Controls value validation and searchable storage. |
| Field classification | Select | Required. | Classify the field itself. A user must be cleared for both batch context and field value before it can be returned. | Controls field-level visibility and export eligibility. |
| Permitted values (one per line) | Long text | Required only for ENUM. | Enter the complete controlled value list, one value per line, before submitting the definition. | Constrains future values to the approved vocabulary. |
| Governance note | Long text | Required for definition submission. | Explain why the field exists, its evidence source and how operators should interpret it. | Becomes attributable definition evidence. |
| Search visible lot data / Attribute field / Attribute value | Search and filters | Optional. | Search only values you are authorised to see; an empty result never confirms a hidden lot or classified attribute does not exist. | Filters the server-scoped register and CSV population. |
| Capture / correction reason | Long text | Required for a new immutable value revision. | Cite the evidence source and reason. Correct by creating a new version rather than overwriting an approved lot record. | Creates attributable immutable batch-attribute history. |
Actions and effects
When to use: When a category requires a typed governed lot fact.
What it does: Creates a definition for independent approval; it does not alter existing batches automatically.
When to use: For a visible batch with an applicable approved definition.
What it does: Creates a new immutable value revision and preserves the prior version.
When to use: After applying the desired visible-field filters.
What it does: Exports only rows and fields permitted by site and clearance; it does not bypass hidden values.
Lists and states
- Definition list: category, key, label, data type, classification and approval state explain the permitted schema.
- Batch register: quantity/location/state context and the current approved visible attribute version remain distinct from stock authority.
Authority boundary
Lot attributes describe existing governed batches. They cannot create a batch, receive material, change quantity, move custody or rewrite an approved attribute version.