Citation and Explainability Engine
A similarity score on its own is a claim without evidence. A report that says "Internal Peer Similarity: 34%" or "External Match: 21%" gives a reviewer a number they cannot check. They do not know which sentences caused it, where those sentences sit in the original file, or whether the match is a real copy or a shared template. The Citation and Explainability Engine closes this gap. It takes every score and penalty the pipeline produces and attaches the exact passages and locations that justify it, so a reviewer can open the source file and confirm the claim in minutes.
This module sits at the end of the detection chain. Module 1 gives every chunk its source metadata (file name, page number, or video timestamp). Module 2 produces the similarity scores between chunks. Module 3 combines those signals into the Internal Peer Similarity, External Match, and AI Content Likelihood percentages. The engine takes those outputs and turns them into a record a human can audit. Its central principle is that explainability is a property of the data flow, not a formatting step added at the end: the report is built from the same citation records that drove the score, so the two cannot drift apart.
Exact Matching Passage Citation Pairs
A citation pair is the basic unit of evidence in the engine. It holds two texts: the offending chunk from the query document (the submission under review) and the matched source chunk (the stored text it resembles). Placing them side by side lets a reviewer see the overlap directly, without reconstructing it from a percentage.
The key requirement is that both texts are quoted exactly from the stored chunk text produced in Module 1, not regenerated, summarized, or re-extracted from the original file during reporting. If the report shows a passage that differs from what the index compared, the evidence no longer supports the score. Each pair is therefore created at the moment a match passes the similarity threshold, and it keeps references to the chunk identifiers so the pair can be traced back to the index.
The pair is the smallest verifiable claim. Everything else in the report, including penalties and summary scores, is built from pairs and can be checked by going back to them.
Citation Metadata and Chunk Similarity Scores
Each citation pair needs context that lets a reviewer find the passage in the original file. That context has three parts: the matched file name, the location within that file, and the chunk similarity score. The file name identifies the source. The location tells the reviewer where to look: a page number for PDFs, a paragraph or section reference for DOCX files, and a start and end timestamp for MP4 clips. The score records how strong the match is.
The score is the cosine similarity between the two chunk embeddings, which measures the angle between two vectors rather than their length. For embedding vectors and , it is
A value near 1 means the chunks point in nearly the same semantic direction. The engine stores this value with the citation, along with the location data, so that every score can be read against a concrete passage. Location formats must be consistent across all three source types, so the reporting layer does not need special cases; the detailed format rules belong to the child article on citation metadata.
Per-Document JSON and Markdown Reports
For each submission, the engine writes two reports: a JSON file for machines and a Markdown file for people. Both are rendered from the same in-memory citation object for that document. This is a deliberate design choice. If the JSON and Markdown were generated separately, a bug in one could make them disagree, and a reviewer reading the Markdown might see different numbers from an automated system reading the JSON. Generating both from a single source of truth prevents that.
The JSON report is the stable, machine-readable form. It contains the score breakdown, the list of penalties and flags, and the citation pairs with their metadata, and it can be validated against a fixed schema. The Markdown report presents the same content in a layout meant for a human reviewer: a summary at the top, followed by the supporting citations. The schema of the JSON file and the layout of the Markdown file are covered in their own child articles.
Penalty Justification Rule
The penalty justification rule states that every penalty or flag in a report must reference at least one verifiable citation. A penalty is a deduction or warning that affects the integrity assessment, such as counting a match toward Internal Peer Similarity or raising an AI-content flag. A penalty without a citation is a conclusion without evidence, and the engine treats it as invalid.
Before writing a report, the engine runs a validation pass. For each penalty or flag, it checks that at least one citation pair exists and that the citation's metadata is complete, meaning it has a file name, a valid location, and a score. Penalties that pass are kept. Penalties that fail are demoted to informational notes. An informational note still appears in the report so the reviewer knows the signal was observed, but it does not change the integrity scores. This keeps the scores honest: they reflect only what the engine can point to.
Report Design for 30-Second Cross-Verification
The report must let a reviewer verify a flagged claim in under 30 seconds. Meeting that target requires a summary-first layout: the headline scores and the number of penalties appear first, so the reviewer can decide quickly whether anything needs attention. Below the summary, the report lists citation pairs, and each pair shows its location directly, such as a page number or timestamp range, so the reviewer can jump to the source without searching.
Citations are ordered by chunk similarity score, highest first. The strongest matches are the ones most likely to be real duplication, so they appear first, and a reviewer who runs out of time has already seen the most important evidence. Each entry is short: the two passages, the location of each, and the score. Lengthy context is left out of the summary, since the full passage is always available in the pair itself. The exact ordering rules and layout details are left to the child article on report design.