Patch Release: Democratizing the "Ultimate Weapon." FactSort (Public Beta) Released.

This is the System Architect at FactSort Lab.

In my previous notes, I have explained the "specifications" of legacy systems like the judiciary and administration, starting from the entry point.
Note 1 was about "if it isn't recorded, it doesn't exist." Note 2 was about "emotional data cannot be processed." And Note 3 was about how "even if you have points (evidence), if you don't have lines (reasoning), the current won't flow."

So, what should you, the user, do?
Today, as one answer to that, I am releasing a patch (FactSort v0.9 Beta) to the public.

This time, I will explain the specs of this patch and why it is a standard protocol for professionals (such as the massive administrative bodies and courts that operate legacy systems, and the lawyers who are the primary users of these institutions).

To be clear, this is not legal advice.
What I am talking about is "preprocessing to pass through the entry point," so that these professionals can handle it without feeling any friction.

1. Protocol: Before winning or getting things approved, you first need a "chronology"

There is a blunt sentence in a practice article from the State Bar of Michigan. I will extract it in English as is.

Translated, it means something like this:
"Chronologies help win cases."
"Your mind should be reserved for thinking, not memorization. Memorization is a job for your software."

What is important, even before talking about winning or losing, is the order of design.

The first thing professionals in sharp suits do is not to calm their emotions, write well, or research precedents and literature; it is the following unrefined, gritty task.

• List when and what happened (Chronology)

• Attach clues for verification to each row (Evidence / Record)

Without this, you cannot decide what to check next (question design, additional materials, missing information).
Human memory is bad at both searching and sorting.
And, inconveniently, it is overly confident.
Therefore, let's leave the tasks we are bad at to software (AI).

2. Reality: That "preprocessing" is heavy. It's so heavy that you collapse at the entrance.

The problem is that creating this chronology is something you "know you should do but can't." You might think it's simple and easy because you know your own situation best, right?
But even in situations where your own rights or assets are at stake, you usually can't do it.

When you are in the middle of some trouble, it usually ends up like this:

• A massive amount of screenshots (and the same screen appears multiple times)

• Multiple recordings (with filenames like "New Recording (3)")

• Fragmented notes (with granularity like "maybe Friday," "evening," "station")

• The more important the event, the more you remember it later and add it (the chronology falls apart even further)

At this point, many people blame themselves.
Saying things like, "I can't organize my thoughts" or "I'm bad at explaining."
However, this is less a matter of ability and more thatthe input is simply "unnormalized data."Of course, professionals can carry this out. Large law firms use associates (brilliant underlings), while sympathetic local lawyers do it by sacrificing their own time. Meanwhile, the administrative side (when receiving applications for welfare or residency, or police receiving complaints or reports of damage), which has no obligation to organize things for you, performs acrobatic dismissals at the door, thinking, "It's too much trouble, so let's just decide there's no need to respond."

In other words, there is a major premise that if professionals have to preprocess this, their time will melt away.

And as a result, it tends to end up as either a processing failure (dismissal at the door), a prolonged delay, being handled haphazardly, or bearing the terrifying time charges of an expert.

I have, of course, experienced this myself.
I dumped records into photos on my smartphone, felt relieved, and three weeks later, I couldn't read my own logs.
My future self is a stranger, after all.
And, log collection is cheapest the first time around.

3. So, a patch: Messy In, Structured Out

The development philosophy is the inversion of the common adage, "Garbage In, Garbage Out."
However, it is cruel to tell someone in the middle of a crisis to "give me clean input."

Therefore, I designed FactSort as follows.

• Input: Whether it's bullet points, unorganized transcripts from voice input, or notes with scattered timelines, that's fine. I want you to input as much as possible. Just have them write down anything that might serve as evidence in bullet points, and don't bother reading the evidence itself.

• Process: Normalization / Sorting / Indexing (the machine does this part)

• Output: A structured document in a "readable format" for the entrance of the judiciary or administration

This patch is not a "writing tool," nor does it perform professional-looking tasks like manipulating legal concepts or statutory provisions.

On the contrary, it intentionally strips away the creativity (i.e., convenient supplementation) that generative AI is supposed to be good at.
The core philosophy of the source code is this.

In short,it only writes from the provided data. For the same input, the output should be the same as much as possible. If this is compromised, trust will be lost at the very entrance.

4. Specs: What FactSort v0.9 outputs (and what it doesn't drop)

This output is tailored to the "preprocessing deliverables" that professionals truly want. There are two main parts.

A. Deterministic Narrative
: It mechanically assembles a chaptered document from the input text. The center is Chapter 2, where it breaks down and arranges items by "Pillar." A Pillar is not a label for inserting legal judgments (no legal weighting is performed at all), but simplya tag for aligning the units of consideration(bundling related facts).

B. Evidence-Linked Timeline
: Using "when and where" as the primary key, it stamps an Evidence ID (e.g., [E01], [E02]) on each line. This is to fix the point (evidence) to a "line" so that inferences can be drawn later.

Furthermore, I have included two subtle but important specifications.
This is the part that is a bit "practical."

• Rescue of orphan events: Even if a fact appears that does not belong to any Pillar, it is always output as "Other (Unclassified)." When humans (professionals) do this, this is actually where things get dropped the most (the dry reason being that it is unnecessary or irrelevant to solving the case or consultation, but since it is important to the emotions of the parties involved, it often causes the most friction later).

• Consistency gate (validate): Before generation, it checks whether the referenced event ID exists, whether the evidence ID format is broken, etc. Since it is most dangerous to produce "plausible-looking output" from broken input, in such cases, it stops at the entrance.

5. Actually, it has always been a specification that "only what is written remains."

The classics are the most concise on this point.

And one more thing. This sounds like a declaration of API specifications.

The heat of oral communication (voice and emotion) evaporates, but the record (log) remains.

To give a slightly black-humored example, in medieval trials by ordeal, there was a practice of making the accused hold a red-hot iron and determining guilt or innocence based on how the wound healed. (Oxford Reference)
Modern systems don't make you hold hot iron, but they operate with a different kind of coldness: "If there is no log, it will not be processed."

The famous quote that captures this modern coldness (the absurdity and the danger) in a single line is this (from a prominent New York judge).

Even a ham sandwich will be processed if the story runs ahead of the facts. In other words, if the other party (the prosecutor or an adversary) unilaterally constructs a story and you lack the "facts" to refute it, even an innocent ham sandwich can be framed as a criminal. That is the specification of the system.
That is precisely why we need to put out a "log of facts" first to lock in the story. This is not about emotion; it is a protocol.

This patch is a Public Beta, but the usage fee is 3,000 yen (3,300 yen including tax) (I have set it as a per-use fee, not a cumbersome subscription).
The reason is simple: variable costs, such as the model's API usage fees, are incurred on the backend, and if I distributed it for free, the service itself would collapse. Beta refers to the quality, not to the cost being zero.
Whether you "buy time" or "do the preprocessing yourself" is left to your own judgment.

6. Release Note: Released today (Public Beta v0.9)

This tool is not meant to deny your emotions.
It is an interface to translate the reality from which your emotions were born into a form that the system can read.

Access it here.

https://factsort.app

Your input can be messy.
However, the output will be rigid. It will not include creativity, and it will not leave any orphans (unprocessed data).
The purpose of this patch is to bring this series of "obvious" standards down to the user level.

FactSort Lab. | System Architect