Confidence scores are not fuzzy semantics

Software teams often slide a score next to an answer and hope that the number itself counts as nuance. Keet’s latest pass through Chapter 10 pushes back on that habit. A field named confidence, likelihood, or uncertain does not automatically mean the platform has moved beyond crisp semantics.

Take a plain business case. A lead-intake system might assign a job request a confidence score of 0.62 because the incoming text probably matches “roof leak” and should go to the urgent-review queue. That can be a useful triage hint. It is not the same as a hard rule that the request is a roof emergency, and it is not proof that the ontology now reasons with uncertainty in some richer semantic sense.

Hadto should keep one business lesson in view. A score may mean a human marked something provisional, an extraction pipeline attached a review hint, an application-layer model emitted a ranking signal, or a workflow wants manual follow-up. Owner-operators need to know whether the system is making a crisp decision, surfacing a soft heuristic, or using a genuinely different reasoning model. Each promise is different, and a platform gets harder to trust when one fuzzy word covers all of them.

Two technical problems that should stay separate

Keet’s study preserves a practical split. Rough modelling is about uncertain classification boundaries: some cases are in, some are out, and some stay in the boundary because the available evidence does not settle the question. Fuzzy modelling is about graded meaning inside the concept itself, where something can be more urgent, less urgent, more risky, or less severe.

Both approaches are real. Neither is equivalent to taping a score onto a crisp class. Hadto should not let a generic label like “uncertain” hide that difference.

Why the distinction matters in operations

Hadto is trying to convert employees into business owners. The software therefore has to do more than output answers. It has to help someone understand what kind of answer they are looking at. When a platform silently mixes binary ontology facts, human review flags, probabilistic model scores, rough certain-versus-possible boundaries, and fuzzy graded truth, the operator has to reconstruct the meaning from context and tribal knowledge.

That is exactly the kind of hidden dependency a transferable business should remove. A new owner should be able to tell whether the system is asserting a hard business rule, surfacing an approximation for review, or relying on a specialized reasoning posture that changes what the result means.

The real risk is overclaim

The problem is not that Hadto lacks fuzzy or rough semantics today. The risk is semantic overclaim. Crisp logic plus annotations can easily look uncertainty-aware even when the underlying semantics have not changed. Once that happens, operators start treating hints like guarantees or graded-looking outputs like formal commitments.

That is dangerous in the situations where ownership matters most: exceptions, borderline eligibility, quality review, and compliance-sensitive decisions. A teachable business needs a cleaner line between what the ontology actually means, what the workflow is estimating, and what the operator still has to judge.

The contract Hadto should publish

The public rule should be blunt. If the platform is crisp today, say it is crisp. If a field called confidence exists only for provenance or triage, say that too. If the business eventually needs true certain-versus-possible querying or graded semantic reasoning, ship that as a separate capability with its own contract.

Do not let a score pretend to be semantics. The next owner should be able to see, in plain language, what is a rule, what is a hint, and what still needs judgment.

---

Source evidence used in this note: Hadto’s internal ontology-engineering progress tracker (reviewed 2026-04-13), an internal uncertainty/vagueness governance issue (internal-only), and existing Hadto blog posts reviewed to avoid duplicating prior notes on reasoning boundaries, semantic lifting, and ontology-to-data linkage.