Frequently Asked Questions

What problem does JCOOP solve?

JCOOP answers the question: how did the system get to its current state? It records the operations that mutate your filesystem so you can reconstruct and audit history, not just restore snapshots.

Is JCOOP a backup replacement?

No. Backups and snapshots preserve the contents of files and directories. JCOOP records the sequence of operations. It does not guarantee that original file contents can be reconstructed in version 1.7.

Does JCOOP record everything?

No. JCOOP records filesystem activity within its configured observation boundary. Like any monitoring system, it has limits.

How does selective restore work?

Policies specify which events to include or exclude during replay. When reconstructing state, JCOOP processes the journal in order and applies only the events allowed by the policy. Excluded events remain in the journal but are not replayed.

Why not simply restore from backup?

Traditional backups are generally point-in-time based. JCOOP enables event-based replay and selective exclusion of recorded operations.

Does JCOOP use a blockchain?

No. JCOOP uses hash chains to make records tamper‑evident, but there is no distributed consensus, mining or token. It operates inside a defined trust boundary.

Can JCOOP restore my files after they were deleted?

Only if the contents are available elsewhere. JCOOP can reconstruct directory structures and state identifiers, but version 1.7 does not preserve file contents. Its purpose is provenance and auditability, not backup.

Is JCOOP ready for production use?

Version 1.7 is a research prototype. It has passed its own test suite but has not been production‑certified or proven at scale. It should be used in controlled environments for evaluation and experimentation.

Can journals be stored separately?

Yes. Journals may be replicated to independent storage locations, allowing evidence to survive even when the original system does not.