The problem: missing evidence becomes 'no issue'

The most dangerous error in an auction file is treating 'no tenants recorded' and 'tenant information could not be read' as the same value. The first is safe; the second is risk. So the first design decision of this engine is a state model.

Three-state extraction

Tenant lists are confirmed absent → [] / unknown → None / present → entries. Only when the sale statement or status survey explicitly says there is no tenancy and no money trace appears is the result confirmed absent; any other read failure stays unknown. Unobtained figures such as distribution tables stay None and are handled conservatively. Flags are set only when true, so something unread never turns into 'false'.

Three-state extraction: absent, unknown, presentConfirmed absent[]Only when the sale statement orstatus survey explicitly says notenancy and no money trace appears→ safeUnknownNoneAny other read failureunobtained figures (e.g. thedistribution table) stay Nonehandled conservatively→ treated as riskPresententriesTenant entries are extractedeach with its evidence→ to the rule decisionFlags are set only when true — something unread never turns into 'false'.
The three states of a tenant list; anything unread stays unknown and is treated as risk (rights_extract.py).

Rule decision: zero model calls

The rights-analysis decision function is a rule engine that checks structured dates, conditions and evidence against domain rules; it does not call a language model. Models are used only for explanatory output such as daily video narration. A queue has re-run confirmed verdicts since September 3, 2026, and since November 1 trap warnings follow through to the detail screen.

Rule decision: zero model callsstructured datesconditionsevidence (three states)Rights-analysis decision functiona rule engine checking domain rulesit does not call a language modelconfirmed verdicts re-run by a queue(since 2026-09-03)Verdict + trap warningsfollowed through tothe detail screen(since 2026-11-01)Where the model is usedexplanatory output only —e.g. daily video narrationWhen a conservative assumption is needed it is written into the result — “assumed full assumption of the deposit, reflected in cost”.
The rights-analysis verdict comes from a rule engine; the model is used only for explanatory output (scoring/rights.py analyze_rights).

Assumptions written into the result

When a conservative assumption is needed, it is written into the result sentence — 'assumed full assumption of the deposit, reflected in cost'. On November 2, 2026 ChatGPT, summarizing listing data received through the Jupgo MCP, distinguished deposit-assumption risk from confirmed assumption and listed what still had to be verified; that frame is on the company's document-reasoning page, unedited.

ChatGPT summarizing a Jupgo MCP result — bid on hold, deposit risk, items still unverified
An actual 2026-11-02 ChatGPT × Jupgo MCP screen: deposit-assumption risk is distinguished from confirmed assumption and the items still to verify are listed; risk and unknown states retained.

Screens say only what they do

On July 26, 2026 the rules no overclaiming, honest notifications and truthful privacy copy went into code; a Korean copy audit on August 15 adopted 52 changes and rejected 9; the ten-year commercial-lease renewal warning was added on August 12. The honesty of the decision engine and the honesty of screen copy are governed by the same rule.

The service opened on this engine: Jupgo

Started on July 8, 2026 as an auction and public-sale prediction engine with serving; the app went up over HTTPS on July 11. On July 17 a breakdown of 6,401 ineligible items showed 96% of the largest stage came from two conditions; Apple payment wiring was revived on August 13. On October 22 an MCP connector for Claude and ChatGPT (listing search, details, today's picks and traps, member OAuth required) went live, with no prices or payment links in the ChatGPT build per platform policy. Since November 4 the blog publisher uses MCP card captures. 2,162 commits since July 8.

From app to MCP: dates from repository history2026-07-08auction predictionengine begins07-11app live over HTTPS07-176,401 ineligibleitems: 96% fromtwo conditions07-26no-overclaiming ruleswritten into code08-12ten-year leasewarning08-15copy audit: 52adopted, 9 rejected09-03verdict re-run queue10-22MCP connector forClaude and ChatGPT11-01trap warnings reachthe detail screen11-04blog publisher usesMCP card capturesIn date order · spacing is not to scale · dates from repository history
From the app launch to the MCP connector: dates from repository history.