AI Document Checker — Project Context & Source of Truth

0. IMPORTANT — READ THIS FIRST

You are working on a production-ready software product whose purpose is to analyze documents and determine whether there is evidence that AI-generated content or AI-related provenance exists in the document.

This document is the project's Source of Truth.

You MUST NOT invent features, requirements, capabilities, integrations, supported formats, AI vendors, detection methods, or business rules that are not explicitly defined in this document or in a later user instruction.

If something is not defined:

When discussing implementation, always distinguish:

  1. Existing capability
  2. Explicit project requirement
  3. Proposed implementation
  4. Future idea / optional enhancement

Never present a proposal as an implemented feature.

1. PRODUCT OVERVIEW

The project is a production-ready document checker.

The initial customer requirement is:

Check Word, Excel, and PDF documents to determine whether there is evidence that AI was involved in creating or modifying the document.

The product is NOT defined as a tool that can mathematically prove that a human or AI authored every piece of text.

The core product principle is:

Direct document provenance / forensic evidence has higher evidentiary value than statistical analysis of writing style.

Therefore:

PROVENANCE / FORENSIC EVIDENCE > STATISTICAL / LINGUISTIC ANALYSIS

Statistical analysis is supplementary evidence only when direct provenance evidence is unavailable.

2. CORE PRODUCT PRINCIPLE

The system MUST separate:

A. Provenance / Forensic Evidence

Evidence extracted directly from the document or file structure.

Examples include, when technically supported:

These are forensic findings.

A finding MUST NOT automatically be interpreted as proof that the entire document was written by AI.

For example:

AI provenance detected ≠ Entire document was generated by AI.

Instead, the system should report the specific evidence found.

B. Content / Statistical Analysis

This is a secondary analysis layer.

Possible techniques may include:

IMPORTANT:

These techniques are NOT considered direct proof of AI authorship.

If provenance evidence is absent, content analysis may provide an indication, but the system MUST NOT falsely claim certainty.

Example:

CORRECT:

"AI-like characteristics detected."

"Statistical analysis indicates elevated AI-like patterns."

"AI involvement cannot be confirmed from document provenance."

INCORRECT:

"This document was definitely written by AI."

3. DECISION HIERARCHY

The system follows this conceptual hierarchy:

Document | v Forensic / Provenance Inspection | +---- Direct evidence found | | | v | Report evidence | +---- No direct evidence | v Statistical Analysis | v Report as indication only

The absence of provenance evidence MUST NOT be interpreted as proof that the document was written by a human.

Therefore:

"Not detected" does NOT mean "Human-written".

It means:

"No direct AI provenance evidence was detected by the available forensic checks."

4. CURRENT SUPPORTED DOCUMENT TYPES

The customer's initial requirement explicitly mentions:

For implementation, this generally means support for:

Other formats MUST NOT be considered officially supported unless explicitly added to the project requirements.

Do not claim support for:

unless they are explicitly added later.

A dependency or open-source library supporting additional formats does not automatically mean that our product supports those formats.

5. EXISTING OPEN-SOURCE REPOSITORY

The project has identified the following GitHub repository as a potentially important reusable component:

Repository:

guillaumemeyer/watermarks-remover

GitHub:

https://github.com/guillaumemeyer/watermarks-remover

The repository is relevant because it contains functionality related to detecting/removing various forms of AI-related or document-related watermarks/provenance information.

IMPORTANT:

The repository is NOT automatically considered part of our production system.

It is a candidate reusable forensic component.

Before production integration, the repository MUST be audited.

The audit should determine:

The project should prefer reusing reliable detection/inspection logic rather than blindly copying the entire repository.

6. IMPORTANT DISTINCTION: DETECTION VS REMOVAL

The identified repository is named "watermarks-remover".

Our product is a CHECKER, not a remover.

The production product MUST NOT modify the customer's original document during analysis.

The original uploaded file must be preserved.

Conceptually:

Original File | +--> SHA-256 / file identity | +--> Forensic inspection | +--> Content extraction | +--> Statistical analysis | +--> Report

The system should preserve the original input as evidence.

Do not add a "remove AI metadata" feature unless the customer explicitly requests it as a separate product requirement.

7. FORENSIC EVIDENCE MODEL

The system should normalize findings from different file formats into a common internal model.

Conceptually:

ForensicFinding

Example conceptual result:

{ "type": "ai_provenance", "source": "document_metadata", "evidenceLevel": "direct", "confidence": "very_high" }

This is an example schema only. Do NOT treat this exact schema as finalized API contract unless explicitly approved.

8. FALSE POSITIVE PROTECTION

A critical requirement is avoiding false interpretation of ordinary content as AI provenance.

For example:

If a document body contains the word "Claude", that alone does NOT mean the document contains Claude AI provenance.

Similarly:

must not automatically become AI evidence.

Raw detector output should be validated and normalized before becoming a product-level finding.

Conceptually:

Raw Detector Finding | v Evidence Validation | v Normalized Forensic Finding | v Product Report

9. DOCUMENT FORENSICS

The forensic layer is more important than the statistical AI detector.

Potential forensic areas include:

DOCX / OOXML

Potential sources:

Do not claim that every item above is currently implemented.

They are forensic areas to evaluate.

XLSX / OOXML

Potential sources:

Again, these are areas for evaluation, not automatically implemented features.

PDF

Potential sources:

Again, do not treat the list as a finalized implementation scope.

10. CONTENT ANALYSIS

Content analysis is secondary.

The system may eventually analyze:

The exact algorithms, models, thresholds, and datasets are NOT finalized unless explicitly specified elsewhere.

Agents MUST NOT invent a detector model or claim that a particular model already exists.

For example, do NOT claim:

"We use XGBoost."

"We use GPT perplexity."

"We use a proprietary neural network."

unless that implementation has actually been approved or exists in the code.

11. CONFIDENCE LANGUAGE

The product must distinguish evidence strength.

Potential terminology:

These labels are conceptual and may be refined during implementation.

Do not expose a numeric "AI probability" as if it were an objective truth.

If statistical scoring is eventually implemented, it must be clearly labeled as statistical/model-based analysis.

Example:

GOOD:

"Statistical analysis score: 0.82"

"AI-like characteristics: High"

BAD:

"82% proven to be AI."

12. MIXED AUTHORSHIP

A document may contain both human and AI-assisted content.

The system should NOT assume:

Document = AI or Document = Human

based on a single finding.

Possible future analysis:

However, these are NOT automatically required features unless explicitly approved.

13. PRODUCTION ARCHITECTURE DIRECTION

Current preferred architecture:

Frontend:

Application Backend:

Document / Forensic / ML Worker:

Database:

Queue:

Object Storage:

Containerization:

This architecture is the current direction, not an immutable requirement.

Do not introduce additional infrastructure such as Kafka, RabbitMQ, Kubernetes, Elasticsearch, etc. unless there is a concrete requirement.

Avoid premature microservice architecture.

Initial target:

Next.js | NestJS API | PostgreSQL Redis S3 | Python Worker

14. RESPONSIBILITY BOUNDARIES

NestJS should own application/business concerns such as:

Python should own computational/document-analysis concerns such as:

The Python worker should not become an uncontrolled second application backend.

The exact communication protocol is not finalized unless explicitly defined.

15. FILE INTEGRITY

The original document is important evidence.

The system should consider:

This is an architectural direction.

Do not claim these features are already implemented unless they exist in the code.

16. VERSIONING

Detection results should be reproducible.

The system should track, when implemented:

A change in detection logic must not silently invalidate historical reports.

Again, this is a requirement direction, not an assertion that the feature already exists.

17. SECURITY

Because users upload potentially sensitive business documents, security must be treated as a first-class concern.

Potential requirements include:

Do not claim a particular security mechanism is implemented until it is.

18. WHAT THE PRODUCT MUST NOT DO

Unless explicitly requested later, do NOT add:

The product is a document forensic/checking system.

19. IMPLEMENTATION DISCIPLINE

Before implementing a feature:

  1. Check whether it is explicitly required.
  2. Check whether it already exists.
  3. Check whether it is only a proposed idea.
  4. Check dependencies and existing architecture.
  5. Avoid duplicate functionality.
  6. Do not silently expand scope.

When uncertain:

ASK instead of guessing.

20. CODE CHANGE DISCIPLINE

When modifying an existing repository:

Do not rewrite a working component merely because another architecture looks cleaner.

21. TESTING PHILOSOPHY

Testing is especially important for forensic detection.

Tests should eventually cover:

  1. Positive forensic evidence
  2. Negative forensic evidence
  3. False positives
  4. False negatives
  5. Corrupted files
  6. Unsupported files
  7. Malformed metadata
  8. Ordinary text that resembles AI-related metadata
  9. Documents with mixed content
  10. Different document versions

Every bug involving a false positive or false negative should ideally become a regression test.

22. CURRENT STATUS

At the beginning of a new session, DO NOT assume that all architecture above has already been implemented.

The project currently has:

Anything else must be verified from the actual repository/code/task context.

23. HOW AGENTS SHOULD RESPOND

When asked to implement something:

First determine whether the request is:

A. Existing feature B. Explicit new requirement C. Proposed feature D. Refactoring E. Bug fix F. Investigation

Then act accordingly.

When reporting progress, use language such as:

"Implemented" only when it actually exists in code.

"Proposed" for a design idea.

"Recommended" for an architectural suggestion.

"Not implemented" when it is only specified but not yet coded.

Never say:

"The system supports X"

unless X has actually been implemented and verified.

24. NO HALLUCINATION RULE

The following are forbidden unless verified:

If source code contradicts this document, inspect the code and clearly report the discrepancy.

Do not silently assume either source is correct.

25. PROJECT NORTH STAR

The product should answer:

"Is there verifiable evidence that AI was involved with this document?"

before attempting to answer:

"Does the writing statistically look like AI?"

The first question is forensic/provenance analysis.

The second question is statistical inference.

The product must never confuse the two.

The central principle is:

DIRECT EVIDENCE > STATISTICAL INDICATION

And:

NO EVIDENCE ≠ PROOF OF HUMAN AUTHORSHP

This principle must remain intact unless explicitly changed by the project owner.