重建學術正當程序：我們如何以 Next.js 16 和 Clocked AI 打造 Margin

"An 87% AI probability score is not evidence. It is an expulsion notice without due process."

In the age of large language models (LLMs), universities face an academic integrity crisis. Commercial AI detectors produce opaque, probabilistic verdicts that can disproportionately affect non-native English speakers, trigger flawed disciplinary proceedings, and erode trust between students and faculty.

Meanwhile, traditional plagiarism checkers focus on finding copied passages across the public web. They can miss intra-cohort collusion (two students in the same seminar sharing work) and ungrounded factual claims, including fabricated research papers, invented benchmarks, and unsupported assertions.

We built Margin for the Clocked Build Challenge 2026 to address these problems.

Margin is an academic review system that helps course conveners and lecturers examine batches of student submissions using a transparent, evidence-first workflow.

Our guiding principle is simple:

The machine flags; the educator decides.

Why We Built Margin with Clocked AI

Margin uses Clocked's inference endpoints to build an evidentiary pipeline that helps educators investigate potential inconsistencies without treating AI-generated scores as proof of misconduct.

Here is how the system works:

Student Manuscripts (.txt / .docx)
              |
              v
    1. Clocked Protect
       Remove direct identifiers
              |
              v
     2. Clocked Compare
       Compare submissions pairwise
              |
              v
      3. Clocked Verify
       Ground claims in course materials
              |
              v
       4. Clocked Rerank
       Prioritize supporting evidence
              |
              v
      Human Reviewer Ledger
       Compare evidence and record decisions

Figure 1: The tactile side-by-side verification sheet highlighting contradictory empirical findings.

Each stage produces information for human review rather than an automatic academic misconduct verdict.

1. Privacy-Conscious Ingestion

Endpoint: POST /clocked/pii

Before submissions enter the comparison workflow, Margin sends them through Clocked Protect to identify and remove direct identifiers such as student names, matriculation numbers, and email addresses.

The system then uses anonymous tokens such as S-01 and S-02 to distinguish submissions throughout the downstream workflow.

This design helps reduce the influence of identifying information during evidence review and supports a more privacy-conscious assessment process.

An important distinction: removing direct identifiers is a privacy safeguard, not a guarantee of FERPA compliance. Actual compliance depends on the complete system, its data handling, institutional obligations, and applicable law.

2. Pairwise Collision and Contradiction Analysis

Endpoint: POST /clocked/compare

Instead of relying exclusively on public-web plagiarism searches, Margin compares submissions within the same cohort.

For a group of (n) submissions, the number of unique pairs is:

n × (n - 1) / 2

Figure 2: Pairwise review interface sorting direct contradictions to the top with pen-wash highlights.

The comparison pipeline looks for two important patterns.

Contradictions: Direct factual inconsistencies between submissions. For example, two papers might describe an apparently identical experiment but report 45 and 120 iterations, respectively.

Shared facts and near-duplicates: Similar reasoning or overlapping passages that may warrant closer inspection. Margin uses pen-wash highlights to make relevant text easier to compare.

These signals are leads for investigation, not proof of copying. Similarity can have legitimate explanations, and contradictory results can arise from different methods, assumptions, or reporting errors.

3. Syllabus-Grounded Verification

Endpoint: POST /clocked/grounding

A submission can sound convincing while containing unsupported claims. Margin addresses this by checking student assertions against the course syllabus or assigned reading pack.

Claims are classified into three categories:

• supported — evidence in the supplied course materials supports the claim.
• partial — the materials provide incomplete or qualified support.
• unsupported — the supplied materials do not provide sufficient support.

Unsupported claims are prioritized for faculty review.

Figure 3: Claims check interface validating student statements directly against the course syllabus.

The distinction matters: a claim that cannot be verified against a particular reading pack is not necessarily false. It may require another source, additional context, or a more careful interpretation.

4. Citation Triage and Evidence Prioritization

Figure 4: The faculty decision ledger with downloadable audit-ready Markdown report.

Endpoint: POST /clocked/rerank

Once Margin identifies claims that need further investigation, Clocked Rerank helps evaluate relevant reading-pack excerpts and determine how useful each piece of context is.

The triage process assigns one of three actions:

• use — the evidence is relevant enough to include in the review.
• expand — additional surrounding context may be necessary.
• skip — the excerpt is unlikely to help resolve the claim.

This helps reviewers focus on meaningful evidence instead of manually inspecting every passage with equal priority.

The final step is the Human Reviewer Ledger, where educators can examine submissions side by side, inspect character-offset evidence, and record their own decisions.

What We Learned: Engineering Margin for Reliability

Building an application around an AI API involves more than connecting endpoints. We also had to consider API costs, repeated requests, concurrency, and failure handling.

1. Guarding Against the O(n²) Pair Explosion

Consider a seminar containing 30 student submissions:

30 × 29 / 2 = 435 unique comparisons

Making hundreds of API calls for a single batch can become expensive quickly.

We introduced two safeguards.

Local n-gram pre-filtering

Submissions are tokenized into character n-grams in memory. Pairs with no detected vocabulary overlap can be pruned before making an API request, reducing unnecessary calls.

This is a cost-saving heuristic, not a definitive test of whether two submissions are related. It must be interpreted accordingly.

The MAX_PAIRS guard

The interface displays a live estimate of the number of comparisons required. A server-side limit, configured through MAX_PAIRS with a default of 20, prevents unexpectedly large batches from proceeding without an appropriate limit configuration.

This adds a second line of defence against accidental credit depletion.

2. Deterministic Content-Hash Disk Cache

Repeated development requests should not needlessly consume API credits.

To address this, we implemented a file-backed cache under clocked_cache/ using SHA-256 content hashes.

The cache-key function looks like this:

export function computeCacheKey(
  endpoint: string,
  payload: unknown
): string {
  const serialized = canonicalJson(payload);

  return crypto
    .createHash("sha256")
    .update(`${endpoint}:${serialized}`)
    .digest("hex");
}

The canonicalJson helper recursively sorts JSON object keys before serialization. This means equivalent payloads produce the same cache key regardless of object-key insertion order.

We also implemented a strict Never-Cache-Error policy. Transient failures are not stored as successful cache results, allowing subsequent requests to retry rather than reusing stale errors.

3. Concurrency Limits, Backoff, and Jitter

Unrestricted parallel requests can overwhelm an external API or cause avoidable rate-limit failures.

Margin wraps outbound requests in a four-worker concurrency pool using p-limit.

For HTTP 429 and 5xx responses, the retry strategy uses exponential backoff with randomized jitter. This spaces retries out and reduces the likelihood that simultaneous requests will repeatedly collide with the same rate limit.

Together, these measures make API usage more controlled and predictable.

Design System: Why Paper, Ink, and Cobalt?

We deliberately avoided another dark dashboard filled with purple gradients and neon effects.

Margin uses a tactile Paper–Ink–Cobalt design language inspired by printed examination scripts, annotated documents, and academic journals.

Warm Paper — #F4F1EA

The background evokes physical exam scripts, term papers, and archival documents.

Deep Ink — #101426

One-pixel borders and hard shadows, such as 3px 3px 0 #101426, create a sense of physical depth and make interface elements feel deliberate.

Translucent Pen-Wash — #C5CEFF

Evidence highlights use an inset box shadow:

box-shadow: inset 0 -0.5em 0 0 var(--wash);

The effect resembles a professor's highlighter passing over a relevant passage.

No UI framework bloat

The interface uses vanilla CSS custom properties rather than Tailwind or an external UI component library.

The result is a focused, document-oriented experience where evidence and reviewer decisions take priority over decorative dashboard elements.

One-Click Judge Mode and Reproducibility

We wanted judges and developers to evaluate Margin without unnecessary setup friction.

One-click judge access

The landing page includes a ⚖️ Judge Access option that authenticates the reviewer into a pre-seeded GNS102 Informatics & Formal Methods batch.

Offline mock engine

When CLOCKED_API_KEY is not configured, Margin falls back to deterministic, precomputed fixture data. This allows developers and judges to explore the workflow without live API credentials.

Automated tests

The project includes 34 automated tests across six test suites, run through Node.js's native test runner using:

npm test

These features make the application easier to evaluate, reproduce, and develop locally.

Try Margin Yourself

Repository: github.com/Josephjbassey/margin-review

Clone the project and start the development server:

git clone https://github.com/Josephjbassey/margin-review.git
cd margin-review
npm install
npm run seed
npm run dev

You can explore the application with the offline mock engine when CLOCKED_API_KEY is omitted. Live Clocked API functionality requires the appropriate credentials and configuration.

Final Thoughts

Academic integrity tools should help educators ask better questions, not replace their judgment with a probability score.

Margin explores a different approach: compare submissions within their actual cohort, check claims against assigned materials, surface relevant evidence, and give educators the context they need to make informed decisions.

There are still difficult questions around privacy, false positives, interpretation, and the limits of automated analysis. Those questions deserve to be part of the design process, not an afterthought.

Our goal is not to automate accusations. It is to make academic review more transparent, evidence-based, and fair.

Built by Joseph John Bassey for the Clocked Build Challenge 2026.

Explore the code: Margin on GitHub