How to Structure Company Information for Investors, and for AI

What actually goes wrong when company information is not structured?

Take a company's investor page after three years of updates. It usually looks something like this: the revenue figure on the homepage comes from last quarter's slide deck. The one in the latest report is more recent and slightly different, because the slide deck used a preliminary number that was revised afterward and nobody went back to update the homepage. A term like "recurring revenue" appears twice on the same site, meaning something slightly different each time, because two people wrote those pages eight months apart and neither read the other's draft. The annual report sits as a scanned PDF. The half year update sits as a web page. Anyone comparing the two has to guess which one holds the current answer.

None of this is unusual. It is what happens to almost any set of company material that grows for a few years without someone actively tending its edges. Nobody planned it this way. It built up one update at a time.

Why does the same mistake confuse both an investor and an AI tool?

The first time an investor reads the wrong revenue figure on that page, nothing serious happens yet. But if that outdated number makes it into an analyst's model, the mistake gets repeated somewhere that matters. An investor rereading two years of updates to work out what "recurring revenue" actually covers usually gives up after the second inconsistency and just asks you directly.

An AI tool reading the same material meets the identical fork, only faster and without the option to just ask you. It still has to choose which version to treat as correct, and when the material disagrees with itself, it can retrieve or repeat the wrong one just as easily as the right one.

The fix here is not a separate technical layer added on top of your existing pages. It is the same fix an unhappy human reader has already been asking for. Some say so directly. Others just stop reading and email you instead.

What breaks first: names, dates, or definitions?

Usually names. When the same thing gets called two different things across your own material, a metric, a subsidiary, a product line, whoever reads it has to guess if that is the same thing twice or something new. Pick the name you will actually use going forward, and apply it consistently on your current pages and evergreen material. Leave historical company information, past releases, past presentations, exactly as they were published; a document like that is a record of what was said at the time, not a page to rewrite. If the name changed since then, a short dated note saying so is enough.

Dates come next. A figure with no clear "as of" date is a figure nobody can trust, because there is no way to tell whether it is this quarter's number or one that quietly went stale two years ago. Put a date on every figure that can change, not just the document that contains it.

Definitions matter most for the terms you did not invent yourself. Something like "adjusted EBITDA" or "like for like growth" means something specific in your business, and it may not match how a competitor or a textbook uses the same words. Define it once, close to where it first appears, and reuse that exact wording everywhere else instead of writing a fresh explanation each time.

What should live in one place instead of scattered across five documents?

Whatever changes. A founder biography that stays the same for years can live wherever is convenient. A figure that moves every quarter, a definition you rely on repeatedly, a policy that governs what you report and when: these need one controlled source, the one place where the current value actually lives and gets updated first. Your release, your deck, your annual report and your website will all still state that same figure, that is normal and often required. What changes is that all of them pull from, and match, that one controlled source instead of five people each keeping their own copy of the truth.

In practice this is usually a single reference page, a short glossary, or a clearly labelled page of current figures that the rest of your site and your reports link to rather than repeat. When a number changes, it changes in one place, and everything downstream is right by default instead of by memory.

Part of what living in one place actually requires is machine readability, a narrower idea than it sounds. It just means information is presented so software can tell what it is looking at without a person explaining it first: a figure labelled with what it measures and as of when, a heading that states what the section actually answers, a glossary entry a tool can match against the term used three paragraphs later. None of that is about writing for a machine instead of a person. It is about not making either one guess.

What should you leave alone?

The writing itself. Structuring your material is not an argument for turning your reports into a spreadsheet or draining the voice out of how you talk about the business. A clear structure and a natural, readable style are not in tension, and treating this as a reason to write more stiffly gets the trade wrong. What needs fixing is the scaffolding around the writing: what is named consistently, what carries a date, what is defined once. The sentences can stay exactly as human as they already are.

It is also worth being proportional about where the effort goes. A one off event page from three years ago that almost nobody links to anymore does not need the same attention as your current investor page or your last two reports. Spend the time where investors and AI tools are actually reading, not on making every page in the archive equally polished.

Whose job is this?

Not a web developer's, and not an item left on an IT backlog for the next site refresh. The decisions involved, what to call something, which figure is current, which definition is the real one, are calls about your own story, not about code. They belong with whoever already owns that story: an investor relations lead where one exists, otherwise the CFO or the founder closest to the numbers.

Once that structure exists, it also becomes the material MIRA reads from to answer investor questions, using only your own approved company information. What MIRA actually is gets its own explanation on the page that owns it: what is a source-grounded IR assistant. The point here is narrower: the same structure that helps a human reader is what lets MIRA point back to the right source instead of the wrong one.

Give one person the job of keeping that structure current, even if it is a small part of a bigger role, and check it against your material once a quarter, at the same time you already touch your reports. Left unassigned, it drifts back into the same mess over successive reporting cycles.

The bottom line on structuring company information for investors and AI

Investors and AI tools alike run into the same three problems: a name used two ways, a figure with no date, a term nobody defined. Fixing those is an editorial job, not a technical one, and your reports keep their own voice throughout. Give the job to whoever already owns your story, and check it as often as you already update your numbers.