Hi Dori, thank you for continuing to engage with the proposal and for taking the time to look closely at the technical side of it. We understand it is a long reply but we think it is necessary to provide the context. Yes, hashes ultimately reach Cardano. But the difficult part of PFMS is not simply taking a hash and putting it into a transaction. To begin with, most of the work in PFMS isn’t just writing code. It’s making that code work against real police hardware and legacy systems. A single device type has many makers (Hikvision, CP Plus, Dahua, etc.) and many firmware versions, a lot of which are old and undocumented. Our engineers build and test an adapter for each one, on site, against real devices like DVRs, NVRs, bodycams, handhelds and ANPR cameras. The same goes for every police system we read from: CCTNS, the Dial 100 control room, the station diary and the armoury. Every piece of code goes through the same cycle: build it, break it on purpose with multiple scenarios (cut the network, cut the power, reset the device clock, tamper with a video), fix it, test it again, and submit the results to the independent assurer and our admin, Cardano Foundation. This process is repeated across hundreds of devices, systems and scenarios, this cycle is where work and the cost go. On top of that, there is security testing, as well as legal fit under the Bharatiya Sakshya Adhiniyam. Everything is then packaged as reusable adapter kits, so the next state or country starts from there, not from scratch. The system therefore includes a Source Engine, edge Capture Engine, Identity Engine, Stamping Engine, Cardano Commit Engine and Verification Engine. The capture layer is explicitly designed to continue operating when connectivity fails, preserve ordered records locally, detect gaps and submit them once connectivity returns. The identity layer binds records to the identity of device and authorised officer that produced them. It is funding the engineering required to make that architecture operate across a real state scale justice environment, along with security testing, assurance, five operational stages of chain of evidence, open source release and deployment tooling. There is also an important distinction regarding IndianChain. Its architecture is an application specific Cardano PartnerChain for government agricultural settlement, record verification and credit workflows. The system has its own execution environment, validator architecture and high frequency operational layer, while Cardano acts as the final settlement and security anchor. The architecture includes PartnerChain validator nodes, deterministic transaction ordering, state transition execution, canonical hashing, settlement services, Cardano transaction submission, proof resolution and replay verification. The PartnerChain handles operational state and workflows; Cardano provides the independently verifiable settlement layer. The architecture anchors important state hashes and audit points so that historical state can later be reconstructed and checked against Cardano. In the case of PFMS, The commit engine enforces stage specific rules around capture, transit, custody and filing through on-chain smart contracts. For example, custody rules can prevent an exhibit from being reissued while already checked out, and invalid transitions remain visible rather than silently changing state. The verification layer then allows prosecution, defence and the court to independently check the same record against Cardano and receive the same cryptographic result. That is why we see Cardano's role here as much more than generic timestamping. It becomes the independent trust and settlement layer underneath a government evidence system.