Inside EDGEBIC's Self-Documenting Reports: A Deep Dive

EDGEBIC's self-documenting reports are powered by a structured glossary in which every non-obvious column carries its own plain-language definition, formula, unit, worked examples, and links to related terms, all from one source of truth that serves both the planner clicking Column Details and an AI agent querying the same data. EDGEBIC by User Solutions treats report documentation as part of the software, not an afterthought in a separate manual. This deep dive is about how that works underneath, and why the structure is what makes it more than a tooltip.

If you want the plain overview of what self-explaining reports look like in use, start with EDGEBIC self-explaining reports explained. This article goes a level deeper into the architecture, because the architecture is the reason the feature holds up.

The Problem With Ordinary Report Documentation

Manufacturing scheduling is full of jargon: schedule performance index, cost performance index, overall equipment effectiveness, gross requirements, on-hand drift. Most people reading a scheduling report are planners, not analysts, and most of the acronyms mean nothing without explanation. The usual answers all fail in the same way.

A tooltip is one line of free text, trapped in the screen, impossible to reuse, and easy to leave out of date. A separate PDF manual drifts away from the software the moment a formula changes, and nobody updates it. A column header abbreviation explains nothing at all. In each case the definition lives somewhere other than the number, and the gap between them grows.

EDGEBIC's answer is to make the definition structured data that lives with the code and travels wherever the number does.

What a Glossary Entry Actually Contains

Each documented column is not a sentence. It is a record with named fields:

Because these are fields, not prose, the same entry can drive several things at once: the in-app details dialog, a definition served to an AI agent, and a knowledge graph you can traverse. That is the whole point of the structure.

Examples Are Concrete, Not Abstract

One design choice does more work than any other: the examples are always concrete value-and-interpretation pairs, and the guidance is to supply three, a nominal case, a good case, and a bad case.

For a schedule performance index, the examples read:

• 1.00, on schedule
• 0.75, behind, earned 75 percent of what should have been earned by now
• 1.15, ahead, earned 15 percent more value than the plan expected

A planner skimming those three lines understands the column faster than from any definition, because the examples anchor the abstract number to a real interpretation. An AI agent grounding an answer uses them the same way. Abstract-only definitions are forgettable. Worked examples stick.

Related Terms Form a Knowledge Graph

Each entry can link to sibling columns on the same report through its related-terms field. Read the schedule performance index and you are pointed to the planned-value hours, the earned-value hours, and the cost performance index. Read those and you are pointed onward. The links form a small directed graph across the report.

For a planner, this is gentle guidance: you may also want to read these. For an AI agent asked about one index, it is a reliable way to suggest the related ones without inventing anything. And the links are validated. An automated test checks that every related term resolves to a real sibling entry, so a typo in a link is caught before it ships, not when someone clicks a dead reference.

One Source, Two Audiences

The design serves a planner and an AI agent from the same data, and that is deliberate.

The planner opens a report, clicks Column Details, and sees a master list of columns on the left and a detail panel on the right. Select a column and its full definition, formula, unit, and examples appear.

The agent asks for a single column and receives the same fields as structured data. Crucially, it quotes the long description verbatim rather than composing its own, which is exactly the behavior you want from an assistant explaining a number: grounded, not invented. The same structure that helps a human skim helps a machine avoid hallucinating.

The Discipline That Keeps It Honest

Structure alone does not prevent documentation from rotting. Discipline does, and EDGEBIC enforces it with automated tests.

Every documented report is checked to be well formed: no empty definitions, no placeholder text, no duplicate column names within a report, and every related-terms link resolving to a real sibling. If a developer adds a report column without documenting it, or ships a definition that is empty or reads "to do," the check fails before the change can ship. And because the definition lives next to the code that computes the number, the expectation is that a formula change and its documentation change happen together, in the same code change. This is the same testing discipline described in how EDGEBIC is tested, applied to documentation.

A Worked Example: Explaining a Low OEE

A supervisor opens the overall equipment effectiveness report for a welding station and sees four numbers: availability 72 percent, performance 95 percent, quality 98 percent, and an OEE of 67 percent. She is puzzled: if the station ran 95 percent of the time it was available, why is OEE only 67 percent?

She clicks Column Details and reads the entries. The availability entry explains that it is the fraction of potential hours the station actually produced, with an example noting that 70 percent means 30 percent of available hours were lost to downtime or staffing. The headline OEE entry gives its formula: availability multiplied by performance multiplied by quality.

Now the arithmetic is transparent. OEE is 0.72 times 0.95 times 0.98, which is 0.67. The performance and quality factors are excellent. The whole shortfall comes from availability: the station was idle or down for 28 percent of its potential hours. The report did not just show her a low number. It told her exactly which factor to investigate. That is the difference self-documenting reports make on the floor.

Why This Matters for a Buyer

Reporting is where scheduling software either earns trust or loses it. A number nobody understands is a number nobody acts on. By building documentation into the reports as structured, tested, self-contained data, EDGEBIC makes its numbers legible to the people who have to act on them, and to any assistant those people point at their data.

The deeper payoff is durability. Because the definitions live with the code and are checked by tests, they do not drift into fiction the way a separate manual does. Two years from now, the explanation you read next to a column will still match the number the software computed. In a plant that runs on trust in its plan, documentation that stays true is not a nicety. It is part of what makes the plan trustworthy.