Back to home SquareLog SquareLog
// How it works / SquareLog Intelligence

Find the right precedent by meaning.

Updated May 26, 2026

SquareLog has a search engine inside it that does something a normal database cannot: it finds Connecticut statutes and case law that are related to your situation, even when your draft and the opinion use different words. We are not going to make that a mystery. Here is exactly what it does, what it doesn’t, and why both matter.

The problem with exact-word search

A regular database is good at answering one specific question: “Find every case that contains the word custody.” That only works if the exact word appears in the opinion.

But the law and the situation don’t describe the same thing the same way. An appellate opinion talks about “the best interest of the child” and “parenting time;” you write a draft about “what’s good for my kid” and “the schedule we had.” Different phrasing, same legal concept. A keyword search across the Title 46b corpus misses most of what matters.

When you’re trying to find the precedent that supports a specific argument in your declaration, that gap is the difference between citing the case that controls and missing it.

1. Every CT statute and opinion gets a meaning address

Think of the engine like a GPS for meaning.

With a regular GPS, a location has coordinates — latitude and longitude — that tell the system where it sits on a map.

AI does the same thing with text. When SquareLog ingests the Connecticut Title 46b corpus — every section of the statute, every published family-court opinion — the AI turns each chunk into a long list of numbers. That list is called a vector. The vector is an address for the meaning of the text — not just the words.

So when the corpus contains an opinion that holds:

Parental relocation requires the court to weigh the proposed move against the established parenting time arrangement.

SquareLog also stores a mathematical version of what that opinion means. Later, a draft passage about “Mom wants to move to North Carolina” can match that opinion — even though the opinion never uses those words.

2. Your draft, turned into a question the engine can answer

When you write a declaration draft and ask Intelligence for relevant precedent, your draft isn’t sent verbatim. SquareLog pulls 3–5 key legal concepts out of your draft — things like “best interest of the child,” “parenting time modification,” “relocation outside the state” — and asks the engine which precedents are about those concepts.

This is on purpose. Sending the whole draft would over-match on irrelevant biographical detail (your kid’s name, the date, the dollar amount). The engine searches the law; the law cares about the concept, not the names.

The difference between a keyword search and this:

  • Keyword search asks: “Do these words appear in the opinion?”
  • SquareLog asks: “Is this opinion about the same legal concept?”

3. Direction, not just words

The math behind this comparison is called cosine similarity, and the simple version is: each piece of text is an arrow pointing at a meaning.

  • If two arrows point in nearly the same direction, the engine treats them as closely related.
  • If they point in very different directions, the engine treats them as unrelated.

That is why a short concept like “best interest of the child” can pull case after case where those exact words may not appear but the holding turns on the same factors.

4. Finding the right matches fast

If SquareLog had to compare every search against every chunk of the corpus one by one, it would be too slow for thousands of statute sections and published opinions.

The engine solves this with a search method called HNSW. The simple explanation: related items are connected to nearby related items, in a kind of map. When a search runs, the engine walks that map — from one related precedent to the next — until it reaches the best matches.

Think of asking a well-organized law librarian: “I need cases about relocation under §46b-56.” Instead of reading every reporter in the building, the librarian knows which volume, then which case group, then which opinion is most likely on point. That is what the engine does, mathematically and very fast.

5. What it actually does in the app

The vector engine’s job is to store and search the meaning of the Connecticut family-law corpus. It does not store your case content, and it does not search across your own SitRep entries.

The main Postgres database stores everything about your case: SitRep entries, the structured events extracted from your raw text (custody exchanges, communications, financials, stability metrics), uploaded documents, audit history. The vector engine stores the searchable meaning of statutes and opinions.

So the app works like this:

  1. You save a SitRep entry, document, or event.
  2. SquareLog stores the real record in your private database. An LLM also extracts structured events from your raw text — one entry might become a missed-visitation event with date, parties, and description, plus a communication event for the text exchange that followed. Those structured records live in Postgres.
  3. Search across your records uses the database directly — by date, by event type, by structured field. It does not go through the vector engine.
  4. When you draft a Declaration and ask Intelligence for relevant precedent, SquareLog extracts the legal concepts from your draft, embeds those concepts, and searches the Title 46b corpus.
  5. The engine returns the most meaningfully related statute sections and opinions, each with its citation.

In plain terms: the database stores your facts. The vector engine helps you find the law that applies to them.

One sentence

SquareLog Intelligence finds the Connecticut Title 46b statute sections and case law that are most meaningfully related to your declaration draft — not just the ones that happen to share keywords.

Things people ask.

Does my draft text get sent to OpenAI?

The concept-extraction step runs your draft through an LLM to identify the key legal concepts. Only the extracted concepts (a short list of legal terms like “best interest of the child”) are sent to the embedding service for the corpus search. Your raw SitRep content stays on SquareLog’s servers and is not sent to any third-party AI for training. The full data-flow story lives in the Privacy Policy.

Does the engine search across my own notes too?

Not yet. Right now the vector engine only indexes the Connecticut legal corpus. Search across your own SitRep entries uses the Postgres database directly — structured filters by date, event type, and the fields extracted from each entry. Semantic search across your own notes is on the roadmap; it isn’t shipping in MVP.

Can the engine miss a relevant case?

Yes. Meaning-based search is statistical, not perfect — the right case can sit just below the relevance threshold and not appear in the top results. Same as asking a law librarian: usually right, occasionally surprising. The safety net is that every precedent the engine returns shows its citation, so you can read it, verify it controls, and pull the opinion yourself from the CT Judicial Branch site before relying on it in a filing.

Why an embedder trained on legal text?

The engine uses Voyage AI’s voyage-law-2, a model trained specifically on legal language. Generic embedders (the same ones that power consumer chat products) lose meaningful retrieval quality on jurisprudential phrasing and citation-style queries. For Connecticut Title 46b, the domain-specific model matters.

Why we’re telling you this

A lot of legal-tech products treat their search as a black box. We don’t. Knowing how the engine works — and where it stops — helps you trust the results, and helps you ask better questions when something matters. If you want to go deeper, we run this on Qdrant, an open-source vector database, with Voyage Law-2 embeddings tuned for legal text. The code is in our repo.

© 2026 SquareLog · Connecticut
About How it works Terms Privacy Security Contact