Digital identity for real products
Traceability technology connecting products, industry and institutions.
Render of an amber bottle with a blue band on the neck.
Explore how a unit is connected to its record.
Reduced motion: use Previous and Next at your own pace.
Illustration · proposal
01 / 10
Illustrated relationship between the product and this step’s data. This is not a scan or a physical check.
The whole journey follows the same product and its record.
Illustration. It does not depict a real Traza installation or product.
02 / 10
Illustrated relationship between the product and this step’s data. This is not a scan or a physical check.
The participant joins and describes the product.
Registering information does not by itself prove that the object matches it.
03 / 10
Illustrated relationship between the product and this step’s data. This is not a scan or a physical check.
The identifier is linked to the unit record.
The signature attests issuer and data integrity. It does not prevent physical copies.
04 / 10
Illustrated relationship between the product and this step’s data. This is not a scan or a physical check.
The mark is applied to the object; activation is still pending.
These states are a narrative proposal; they do not extend the verification engine.
05 / 10
Illustrated relationship between the product and this step’s data. This is not a scan or a physical check.
The programme defines who activates and what must be checked first.
Illustrated transition. No activation date or real authorisation is invented.
06 / 10
Illustrated relationship between the product and this step’s data. This is not a scan or a physical check.
Units, cases and pallets keep their own identifiers.
Querying the group does not prove that each unit is physically inside.
07 / 10
Illustrated relationship between the product and this step’s data. This is not a scan or a physical check.
When items are ungrouped, the relevant relationships are closed.
A historical relationship does not prove where the product is today.
08 / 10
Illustrated relationship between the product and this step’s data. This is not a scan or a physical check.
The record is incomplete. Let us review the reason and the expected coverage.
An event not received is a state, not a cause. A gap does not prove fraud.
09 / 10
Illustrated relationship between the product and this step’s data. This is not a scan or a physical check.
The lookup separates the evidence; it does not give an authenticity score.
The lookup does not certify physical authenticity.
10 / 10
Illustrated relationship between the product and this step’s data. This is not a scan or a physical check.
A signal helps prioritise review. It does not make an accusation by itself.
Example: the outcome may confirm or correct the state. It does not modify the record.
Illustration · proposal
Related record: TRZ-7F2K-4K7Q-92FA. The story does not modify this record.
The whole journey follows the same product and its record.
Who contributes or decides: Programme participant.
What changes: The unit to be identified is defined.
Illustration. It does not depict a real Traza installation or product.
The participant joins and describes the product.
Who contributes or decides: Participant and programme owner.
What changes: An accountable party, the description and the identification rules are linked.
Participant: Defined responsibilities and permissions.
Product: Description and declared data.
Registering information does not by itself prove that the object matches it.
The identifier is linked to the unit record.
Who contributes or decides: Issuer authorised by the programme.
What changes: Narrative state: issued. This does not yet imply application or activation.
Identity: Issued · not yet applied.
The signature attests issuer and data integrity. It does not prevent physical copies.
The mark is applied to the object; activation is still pending.
Who contributes or decides: Person responsible for application on the line.
What changes: Application is recorded separately from authorisation to activate.
Application: Mark applied to the object.
Activation: Pending · not yet active.
These states are a narrative proposal; they do not extend the verification engine.
The programme defines who activates and what must be checked first.
Who contributes or decides: Authorised role under the programme rules.
What changes: The state changes from pending to active and the change is documented.
Narrative state: Active · change documented.
Illustrated transition. No activation date or real authorisation is invented.
Units, cases and pallets keep their own identifiers.
Who contributes or decides: Participant grouping the units.
What changes: Parent-child relationships are created between levels.
Pallet: Own identity; linked to the case.
Case: Own identity; linked to the unit.
Unit: Its identifier does not change when grouped.
Querying the group does not prove that each unit is physically inside.
A container may be another level with its own identity. A lookup returns the associations in the record, not a physically verified inventory.
When items are ungrouped, the relevant relationships are closed.
Who contributes or decides: Participant receiving or ungrouping items.
What changes: The relationship is no longer active; its previous history remains.
Case-unit relationship: Closed in the story.
Unit identity: Preserved.
A historical relationship does not prove where the product is today.
The record is incomplete. Let us review the reason and the expected coverage.
Who contributes or decides: Participants providing events and the review team.
What changes: Received events are compared with what was expected to be recorded.
State: Event not received.
Review: Pending synchronisation, a documented exception or another reason to establish.
An event not received is a state, not a cause. A gap does not prove fraud.
Events include the contributing role, place and declared time. Without knowing expected events and coverage, an unrecorded movement cannot be inferred.
The lookup separates the evidence; it does not give an authenticity score.
Who contributes or decides: Person looking up and comparing the product.
What changes: Available information is shown without conflating the checks.
Signature: Issuer and integrity of the signed data. It does not prevent physical copies.
Registry: Identifier found and declared status. Does not demonstrate location.
Data: Information to compare. The person checks whether it matches the product.
Signals: Patterns in the available records. No alerts does not mean no risks.
The lookup does not certify physical authenticity.
A signal helps prioritise review. It does not make an accusation by itself.
Who contributes or decides: Review or inspection role, according to the programme.
What changes: The review and its documented outcome are added to the record.
Signal: An observation that merits review.
Outcome: Documented human decision; not an automatic verdict.
Example: the outcome may confirm or correct the state. It does not modify the record.
From the need to the pilot, evaluation and continuity.
Reduced motion: use Previous and Next at your own pace.
Proposed route · subject to the applicable regime
01 / 08
Existing controls and visibility gaps are reviewed.
Proposed route, not a universal legal formula or a deployment commitment.
02 / 08
What gets identified, who records, what is public and what is protected.
Ownership is not automatically assigned to the state or to Traza.
03 / 08
Consult, document and respond to the comments received.
Consultation may adjust or confirm decisions; it does not require changing everything.
04 / 08
The pilot requires prior authorisation or contracting.
The public route depends on the applicable regime; a private agreement does not replace that authority.
05 / 08
The pilot tests application, reading, capture and integration.
Attributing an improvement is difficult. Comparison alone does not establish causality.
06 / 08
The supplier does not write the independent audit findings.
An audit may approve without findings. The correction shown is only an example.
07 / 08
Expansion rests on measurable acceptance, cost and capacity.
Traza is a private company. This story does not establish a contract award or endorsement.
08 / 08
Ownership, custody, permissions and portability: agreed per programme.
Proposed continuity, not an established deployed capability. It requires agreements and tests.
Proposed route · subject to the applicable regime
Existing controls and visibility gaps are reviewed.
Who contributes or decides: Buyer and programme participants.
What changes: Scope, use cases and what to measure are agreed.
Industry route: Voluntary agreement between the parties.
Public programme: Authority and procurement decisions under its jurisdiction.
Proposed route, not a universal legal formula or a deployment commitment.
What gets identified, who records, what is public and what is protected.
Who contributes or decides: Programme owners and participants.
What changes: Data, permissions, responsibilities and costs to agree are documented.
Data and access: Ownership, custody and permissions defined per programme.
Operations: Equipment, consumables, integration and support: responsibilities to agree.
Ownership is not automatically assigned to the state or to Traza.
Consult, document and respond to the comments received.
Who contributes or decides: Industry, operators and programme owner.
What changes: Comments receive a response and remain traceable.
Consultation may adjust or confirm decisions; it does not require changing everything.
The pilot requires prior authorisation or contracting.
Who contributes or decides: Buyer, pilot owners and evaluation team.
What changes: The method is agreed and the starting position is measured before the pilot.
Prerequisite: Pilot authorisation or contracting.
Baseline: Prior measurement with an agreed method and comparison.
The public route depends on the applicable regime; a private agreement does not replace that authority.
The pilot tests application, reading, capture and integration.
Who contributes or decides: Pilot participants and proposed technical supplier.
What changes: Measure again and compare with the baseline.
Attributing an improvement is difficult. Comparison alone does not establish causality.
The comparison may use a control or a phased rollout, according to the agreed method. No unsubstantiated Traza percentages, deadlines or results are shown.
The supplier does not write the independent audit findings.
Who contributes or decides: Independent evaluator and programme owner.
What changes: Evidence is assessed against the acceptance criteria.
Possible outcome: Meets the agreed criteria.
Example with a finding: Correct an incomplete capture and check it again.
An audit may approve without findings. The correction shown is only an example.
Expansion rests on measurable acceptance, cost and capacity.
Who contributes or decides: Buyer and competent authority or parties.
What changes: The decision is to proceed, adjust or not expand; onboarding may be phased.
Traza’s technical role · proposal: Issuance, events, lookup, integration and portability; scope to agree.
Traza is a private company. This story does not establish a contract award or endorsement.
Ownership, custody, permissions and portability: agreed per programme.
Who contributes or decides: Programme owner, participants and suppliers.
What changes: Export and supplier transition are tested without losing records or permissions.
Onboarding: Phases, training and support to agree.
Exit and continuity: Open formats, complete export and supplier replacement.
Proposed continuity, not an established deployed capability. It requires agreements and tests.
The platform, in action
Try what a person can query, how a supply chain is organized and what information a control team reviews.
Compare the product with its record and understand each result, including its limits.
Try a queryFollow a unit’s events: who reports them, when they happen and what information they contain.
Explore the journeyExplore reports, signals and field inspections with role-based permissions.
Open the control viewEach perspective works on the same record: what changes is what each role can see and do.
A multisector proposal
Every industry has its products and every program has its rules. Traza proposes connecting identities, events and queries with a scope and responsibilities defined for each implementation.
Beverages and food are example use cases. Integrations, permissions and operations are agreed and validated for each program.
Meet Traza
Traza is a private company providing traceability services to industries and public entities. This site describes the platform; it does not establish contracts or government endorsements.
Write to us and we will reply within business days.
