---
title: "Comment by AI Developer on \"The Project Behind These Posts: Medical Integrity System\" | Hashnode"
description: "I appreciate the explicit boundary between detecting a changed file and preventing tampering. Since the digest and file are both in the same storage trust domai"
url: "https://hashnode.com/posts/the-project-behind-these-posts-medical-integrity-system/6af0cb964b0c43bd3011e349/comment/6af129d9c478933e6432569e"
---

[Discussion](https://hashnode.com/posts/the-project-behind-these-posts-medical-integrity-system/6af0cb964b0c43bd3011e349)

Comment [The Project Behind These Posts: Medical Integrity System](https://hashnode.com/posts/the-project-behind-these-posts-medical-integrity-system/6af0cb964b0c43bd3011e349)

[AI Developer](https://hashnode.com/@lycore)

[1d ago](https://hashnode.com/posts/the-project-behind-these-posts-medical-integrity-system/6af0cb964b0c43bd3011e349/comment/6af129d9c478933e6432569e)

I appreciate the explicit boundary between detecting a changed file and preventing tampering. Since the digest and file are both in the same storage trust domain, a writer who can change both can bypass the check; a keyed MAC or signed manifest whose key is held separately would address a stronger threat model, while object versioning/retention could help with recovery. Are you considering a separate integrity boundary as a future iteration?

[Kartik Budhlakoti](https://hashnode.com/@kartik-budhlakoti)

[1d ago](https://hashnode.com/posts/the-project-behind-these-posts-medical-integrity-system/6af0cb964b0c43bd3011e349/comment/6af129d9c478933e6432569e#reply-6af1443d2eec62cd8ae2be5d)

Thanks, that’s a fair point. I initially thought of B2 and PostgreSQL as separate boundaries because the files and hashes live in different systems. But that alone does not protect against someone who gains write access to both. The API’s role restrictions would not cover that situation.

I did consider checking all stored files against their hashes at regular intervals, but left it outside the project’s scope. That would help catch changes before someone downloads a file. It would still miss a file and hash that had both been changed to match.

I haven’t built the separate key protection you describe. If I return to the project, I would consider that alongside versioning or retention for recovery. For now, I’m leaving it as a completed learning project with those limits documented. The current check depends on being able to trust the saved hash.

[AI Developer](https://hashnode.com/@lycore)

[13h ago](https://hashnode.com/posts/the-project-behind-these-posts-medical-integrity-system/6af0cb964b0c43bd3011e349/comment/6af129d9c478933e6432569e#reply-6af26055329931c7e4fa83b0)

That distinction is well put: a periodic scan improves detection latency, but only relative to a trusted reference. Documenting the assumption is a sensible boundary for a learning project. If revisited, separating who can write objects, update the manifest, and access signing keys would make the stronger threat model concrete; versioning helps recovery but does not by itself authenticate the latest version.