Citely: notes on citation intelligence and academic trust

The problem

Academic writing has a trust problem that is easy to underestimate.

A citation can exist but fail to support the claim. A paper can be real but irrelevant. A source can be strong in one context and weak in another. Students and researchers often need to answer three separate questions:

1. Does this cited paper exist?
2. Does it support the sentence it is attached to?
3. Are there stronger sources nearby?

Citely is my attempt to build around those questions.

Status and evidence

Citely is currently a private testing product, with public evidence summarized in the project evidence page. I am treating it as a product architecture case rather than a public SaaS launch note.

That distinction is important because academic tooling should earn trust slowly. A citation product should not be marketed like a magic writing button. It should show what evidence it checked, what it could not access, and how confident the answer should be.

Why search alone is not enough

A normal search product helps you find papers. That is useful, but citation work is more specific.

When a user asks whether a citation supports a claim, the product has to compare claim text, paper metadata, abstract, full text when available, and sometimes the surrounding paragraph. It also has to show enough evidence that the user can judge the answer.

That means Citely is not just a wrapper around academic APIs. It needs a pipeline:

• search academic sources
• parse and normalize paper metadata
• extract useful text from PDFs
• chunk and embed source text
• retrieve relevant evidence
• compare evidence with the claim
• explain uncertainty instead of hiding it

The system shape

The architecture uses Vue 3 and TypeScript on the frontend, FastAPI on the backend, Supabase for auth, storage, Postgres, row-level security, and pgvector. It also connects to academic data sources such as Semantic Scholar, OpenAlex, Crossref, PubMed, arXiv, and PDF parsing with PyMuPDF.

For model work, the product uses embeddings and RAG-style retrieval. The goal is not to let an LLM decide everything from memory. The goal is to make the model read the best available evidence and then produce a bounded answer.

Payments and credits are handled with Stripe because citation auditing can become expensive when documents, embeddings, and repeated checks are involved.

The interface standard

The interface should make uncertainty visible. My standard for a useful citation audit is that the user can see four things without guessing:

1. the claim being checked
2. the source metadata
3. the passage or abstract evidence used
4. the reason the tool believes the citation does or does not support the claim

A score by itself is not enough. A score can help triage, but the evidence has to remain visible.

The product constraint

The most important constraint is that the product should not sound more certain than it is.

In academic work, a useful answer might be:

• This source supports the background claim, but not the causal claim.
• This paper is related, but the cited sentence overstates the result.
• The paper appears relevant from the abstract, but full-text access is needed.
• A stronger source would be a systematic review or a newer paper.

Those answers are less flashy than a simple yes or no. They are also much more useful.

What makes the work hard

Citation intelligence sits between information retrieval and user trust.

The engineering problems are familiar: APIs, embeddings, chunking, PDF parsing, auth, storage, billing, workers, deployment, tests. The product problem is harder: users need to understand why the tool reached a conclusion.

So the interface has to expose evidence. A citation audit should not only return a score. It should show the relevant passage, the claim being checked, the source metadata, and the reason for the match or mismatch.

What I would improve next

The next product question is how to compare sources against each other. Checking one citation is useful, but research work often needs ranking:

• Which source is strongest for this claim?
• Is there a newer paper?
• Is this a primary source or a secondary summary?
• Does the source support the exact sentence or only the general topic?

That is where Citely becomes less like a checker and more like a research assistant with receipts.

Why this matters to me

Citely connects to a broader theme in my work: building tools that make knowledge work less fragile.

A good citation product does not write the paper for the user. It helps the user become more careful. It makes a hidden quality-control step visible.

That is the kind of AI product I want to build more of: not magic, not a shortcut around thinking, but a system that makes serious work easier to verify.