01
Custody event history
Operational changes are represented as a traceable history instead of only overwriting the latest record state.
2024Delivered system scope
xITAD ERP
Enterprise chain-of-custody system
A controlled custody workflow with role boundaries, traceable events, and generated certificates.
A chain-of-custody ERP with an auditable ledger, role-based access, controlled operational workflows, PDF certificate generation, and record history.
Public product view
Role
Product architecture and engineering
Platform
Operations web application
Delivered
2024
Evidence
Delivered system scope
01 / Context
The product problem
Chain-of-custody software must preserve who handled an item, what changed, and which certificate was produced while limiting every operator to the records and actions their role permits. The history has to remain useful to operations without weakening the control boundary.
Delivered system outcome
The delivered system connected operational records, access control, history, and certificate output around a shared custody ledger. Operators could work through defined responsibilities while generated documents consumed controlled record data.
02 / Product scope
What the system was built to do
Each capability is tied to the public product scope. No commercial or adoption metric is inferred.
02
Role-based operations
Users see and perform the actions allowed for their operational responsibility through enforced role boundaries.
03
Controlled certificates
PDF certificates are generated from accepted ledger data so document output follows the same controlled source of truth.
04
Operational review
Record history supports review of who changed a custody item and how it reached its current state.
03 / System flow
How the main workflow connects
- 1
An authorized operator creates or receives an item record.
- 2
Custody events are added as the item moves through the operation.
- 3
Role checks gate reads, changes, and protected actions.
- 4
Accepted ledger data is used to generate the required certificate.
- 5
The history remains available for operational review.
04 / Engineering
Decisions behind the delivery
The documented stack pairs a React operations interface with FastAPI and PostgreSQL. Authorization and audit events sit at the trusted data and API boundary, while certificate generation consumes controlled ledger records.
Technology
- React
- FastAPI
- PostgreSQL
- RBAC
01
Put authorization at the data/API boundary
The React interface communicates intent, while FastAPI and PostgreSQL remain responsible for enforcing protected operations.
02
Generate documents from controlled records
Certificates derive from accepted ledger data to avoid a separate, inconsistent document state.
03
Preserve event history
A traceable operational history provides more useful custody evidence than a record containing only its latest values.
05 / Handoff
Delivered scope
- Chain-of-custody ledger and auditable record history
- Role-based access control for operational users
- PDF certificate generation from controlled data
- Data workflows shaped around documented privacy and access requirements
Before using this as a buying reference
Contribution, review points, and evidence limits.
Client work: founder contribution to architecture and engineering. This is not a claim that ZamDev AI owns the client business or its records.
Useful questions for an evidence review
- Follow an asset through custody events, responsible roles, and record history.
- Check how a generated certificate relates to the underlying controlled record.
- Review access-control scope and exceptions without exposing client records.
No client-approved acceptance report, time-saving benchmark, or customer quotation is published here. The listed controls describe the implemented scope, not an independent security certification or proof of regulatory compliance.
Build the next one
Need a product with this level of technical ownership?
Share the product, current codebase, or core workflow. You will receive a direct technical response with the right next step.