Batch / Group Association

A batch is a group record that associates a defined set of registered QR identities sharing a common origin fact — such as a production run, shipment or certification lot — so that they can be tracked, operated on and audited together, without merging their individual compliance conditions.

The batch record itself is a first-class object: it has its own identifier, its own set of member identities, and its own batch-level facts. It is not simply a label applied after the fact to a query result; it is a maintained association that individual identities point back to.

Batch association is deliberately narrower than 'anything a company groups for convenience.' It is reserved for identities that share a genuine originating fact, which is what makes a batch-level operation meaningful across the whole group rather than a coincidence of timing.

A batch record captures facts that are true of the group as a whole, plus the membership list that ties individual identities to it.

None of these fields substitute for an individual identity's own record. A batch record references its members; it does not absorb their individual dossiers, conditions or history.

The most important discipline in batch design is separating what is genuinely true of the batch from what remains the property of each identity individually.

A batch-level condition is best understood as a fact attached at the group level that feeds into, rather than replaces, each member's individual evaluation. A recall affecting an entire lot, for example, is recorded once at the batch level, but its effect on any given identity's condition still runs through that identity's own evaluation, since one unit in the lot might already be independently revoked for an unrelated reason.

A batch-level fact is an input to individual evaluation. It is never a substitute for it. Every member identity retains its own condition, computed on its own record.

A batch operation is an action initiated against the batch record that is designed to propagate to some or all of its members, rather than requiring the same action to be repeated identity by identity.

1. 1Operation is initiated at the batch levelAn authorized operator initiates an action — for example, recording a shared recall fact, closing the batch to new members, or reassigning the responsible company.
2. 2Scope of propagation is determinedThe system determines which members the operation applies to — typically all current members, unless the operation specifies a subset.
3. 3Each member's evaluation is re-runRather than writing a single group-wide condition, the batch-level fact is fed into each affected identity's individual evaluation.
4. 4Per-identity outcomes are recorded independentlyEach identity's resulting condition, and any state change it produces, is recorded against that identity, referencing the batch operation as the cause.
5. 5Batch record reflects the operation's historyThe batch record retains a log of the operation, distinct from but linked to the individual outcomes it produced.

• A batch-wide recall records a shared fact that every member's evaluation must account for, without asserting the same resulting condition for every member.
• A batch reassignment of the responsible company updates Route 20's ongoing relationship for every current member at once.
• Closing a batch prevents new identities from being added but does not alter the condition of existing members.
• Removing an identity from a batch ends the batch's influence on that identity's future evaluations without altering its historical record of having once been a member.

A batch association is not valid simply because a company groups identities together for convenience. It is invalid, and must be rejected or corrected, under specific circumstances.

• ✓The member identities do not share the declared originating fact — for example, units from two distinct production runs placed in the same batch.
• ✓The batch claims a responsible company that does not match the ongoing relationship (Route 20) recorded for one or more of its members.
• ✓A member identity is added to a batch after the batch has been closed to new members.
• ✓A member identity is claimed by two open batches at once with conflicting batch-level facts, without one association being resolved as the authoritative one.
• ✓The batch record's originating fact conflicts with an individual member's own registration data, such as a batch dated before one of its members was even registered.

Where a batch association is found invalid, the affected member identities are not automatically penalized. Their individual conditions continue to be evaluated on their own record; the invalid batch link is corrected or removed without asserting anything negative about the identity itself.

An invalid batch association is a record-keeping problem to correct, not evidence of an identity-level compliance failure. The two are evaluated independently.

Batch association sits alongside the identity-to-company relationship, giving companies an efficient way to act on groups of identities while validation preserves each identity's individual condition.

Where a batch record appears to contradict QRCodex.us on membership or operation history, Codex governs and the batch record is corrected against it.