The Elevare Correction Standard
The Recommendation Standard governs what we send out. This is its sibling: the standard that governs what comes back. A person fixing a stale fact, a rep marking a brief wrong, a reviewer rejecting a draft, an outside signal that invalidates last quarter's assumption: one standard routes every one of them, requires evidence, sends it to the person who is allowed to approve it, and keeps a record either way. We publish it, with a worked example from our own work, so you can judge it before you hire anyone, including us.
Why a standard for corrections
Most companies treat a correction as a small, private act. Someone notices a number is wrong, fixes it, and moves on. Nobody asks why the wrong number was there, whether the fix should change how the next ten reports get built, or who was actually allowed to approve it. The correction improves one document. Nothing else gets better.
A correction that is typed, routed, and evidenced does more than fix a mistake. It asks a second question: does this change anything beyond the one place it was found? Most of the time the answer is no, and it stays a note. Sometimes the answer is yes, and the correction becomes a rule, a policy, or a new decision that every future person and every future AI session inherits without having to rediscover the problem.
The standard also protects against a different failure: a correction nobody was allowed to make. AI can propose a change to a fact, a document, or a plan faster than a person can review it. That speed is only useful if a person remains responsible wherever judgment, authorization, risk, or an irreversible action requires one. This standard says, in one place, where that line sits.
The loop
Every correction, regardless of who or what noticed it, moves through the same sequence: it happens during work, gets noticed, gets typed and routed, gets evidence attached, gets proposed, gets reviewed by the person who owns that destination, gets a decision, and, if it should affect future work, gets versioned, kept, and carried forward into the next session and the next workflow.
A corrected fact gets a successor. The old one is marked superseded and kept. Nothing is erased, so anyone can still see what the company used to believe and when it changed.
A model's reading of something can't become a fact by being written down. It stays labeled as an interpretation until a person or a verified source confirms it.
The default posture for every correction is to propose it, not apply it. Automatic application is reserved for edits with no judgment in them at all, like fixing a broken link.
That a change is demonstrably safe to make doesn't mean it gets made without asking. A person approves it.
When two sources disagree, the disagreement is written down with both sides and the reasoning, and the resolution is recorded. Nothing quietly picks a winner.
Routine detail stays in the log. A correction earns a place in a rule, a policy, or a decision only when it will actually change future work.
Eight kinds of correction, and where each one goes
Not every correction is the same shape. A stale price and a repeated mistake don't belong in the same place, and they don't need the same person's sign-off. We sort every correction into one of eight types, each with its own destination and its own approver.
A fact is out of date, wrong, or no longer holds. Goes to the fact record as a new version; the old one is superseded. Approved by whoever owns that source, or the map owner.
A choice was made that replaces or adds to a prior one. Goes to the decision record; the prior decision is marked superseded. Approved by the person who has the authority to decide (at Elevare, that is Josh).
The same correction has been made to our output three or more times. Becomes a policy. Approved by the map owner.
A way of doing a task worked and should be reused. Becomes a documented skill. Approved by whoever owns that workflow.
A multi-step task recurs and can be written down with a stopping point. Becomes a workflow. Approved by whoever owns that workflow.
The same mistake happened twice, or an action turned out to be dangerous or hard to undo. Becomes a stopping point or a prohibition. Always approved by a person, not an agent.
Two sources or records disagree. Logged with both sides and the point of disagreement named, then resolved into whichever destination wins. Approved by whoever owns the winning source, or the map owner if that's unclear.
An observation from outside the company (a signal, an event, a filing) invalidates something we assumed, decided, or believed inside it. Goes to the fact or signal record, with the affected decision flagged for review. Approved by whoever owns that decision.
What evidence a correction has to carry
A correction with no source is a comment, not a correction. Every one we accept carries the same evidence block the Recommendation Standard requires of a recommendation, plus where it came from and when.
- Class. Was this directly present in a source (observed), computed from observed inputs (derived), a person's or a model's reading of it (inferred), or a guess still to be tested (a hypothesis)? Only observed and derived facts are promoted as facts. An inferred reading can become a hypothesis. It never becomes a fact just by being written down.
- Source. The URL, the file and the exact lines, the system and the record, or the person who said it.
- When we learned it, and when it became true. Both dates matter and they aren't always the same.
- The artifact. Where the source is a document, the exact passage the correction rests on, not a paraphrase of it.
- Confidence. Stated as a band, from unambiguous down to needs-review, and never blended with how authoritative or how recent the source is; those are separate questions.
- Authority. Where this source sits in the company's own order of which system is trusted for which kind of truth.
Review, disposition, and who is allowed to approve what
Every correction moves through the same review states: drafted, reviewed, accepted, rejected, or sent back for revision. Every acceptance also records a disposition: kept as proposed, kept with a rewrite, merged with something else, split apart, downgraded to a lower confidence class, moved to a hypothesis instead of a fact, or rejected outright.
Anyone, including an agent, may propose a correction. Only a person may approve a change to a rule, a policy, or a decision. Facts and outside signals can be approved on a lighter policy once their source is verified, because the risk of a wrong fact is smaller and easier to reverse than the risk of a wrong rule. An agent never approves a change to the company's own map, rules, policies, or decisions; that responsibility stays with a named person, every time.
A correction is only promoted when all of the following are true: it was accepted, the approver is recorded, the evidence is complete, the new version points back to what it replaces, the log has an entry, and the change would actually affect future work. Anything short of that stays in the log as a note rather than becoming part of what the company knows.
Versioning, staleness, and rollback
Nothing is overwritten in place. Every durable record carries a version, the date it became true, and, once it's replaced, the date it stopped being current and what replaced it. A correction is one committed change, not a series of silent edits.
Staleness is a state, not a disappearance. Different kinds of knowledge get reviewed on different schedules: the company's own map gets checked every thirty days or whenever something material changes; a decision gets revisited the next time a related decision comes up; a fact gets checked as often as its source refreshes. A fact past its review date is flagged as stale rather than quietly trusted, and anyone retrieving it is told so.
When two sources disagree, the disagreement itself becomes a record: what's being claimed, which sources are on each side, and what would resolve it. It's resolved in a fixed order: the company's own source-order ruling first, then which source is more authoritative, then which is more recent, then which is better supported. The resolution states which side won and why, so the same wrong answer never gets proposed twice.
Every applied correction can be undone. For a document, that means the exact change and the version it was made against are both recorded, so it can be reversed cleanly. For an append-only record, a correction is never an edit; it's a new entry that supersedes the old one, which means "undoing" it is just another correction, logged the same way. If a rollback can't be verified as clean, it's recorded as failed, never claimed as clean.
The correction record
Every correction, however small, leaves the same kind of trail: what kind of correction it was, who or what proposed it, when, where it's going, what it changes from and to, the evidence behind it, anything it conflicts with, who reviewed it and when, what was decided, what it replaced, and, the part that matters most, what actually got re-read, reloaded, or updated as a result. That last field is what separates a correction from a note. If nothing downstream changed, it was a note.
The log is append-only and readable without any of our own tooling: a plain, dated record that grows one entry at a time and is never edited after the fact.
How it reaches the next session
A correction is only worth the standard if it actually changes what happens next. Five things make sure it does:
- The company's map, rules, and policies are re-read at the start of every session, so a correction to any of them takes effect immediately, with no separate mechanism required.
- Retrieval always prefers the current version. A superseded record is only returned when someone specifically asks for history.
- A documented skill or workflow updates the next time it's used, not the next time someone remembers to redeploy it.
- An agent picks up the log since its last run before doing new work, so it never repeats a mistake that was already corrected.
- When an outside observation touches something we already decided, it automatically opens a review of that decision, addressed to whoever owns it, which is exactly how a correction can turn into a recommendation, written to the Recommendation Standard, triggered by something that changed outside the walls.
A worked example, from our own work
In July we produced a weekly account brief for a design partner. It was a good brief. Two of its dated claims had no source attached to them inline, and one had been overtaken by a newer filing we hadn't caught. We caught the problem before it went out and pulled the edition back.
The easy fix would have corrected the two lines and shipped a corrected copy. The document gets better. Nothing else does.
The routed fix asked a harder question: why was an unsourced claim allowed into the brief at all? The answer wasn't a fact error. It was a missing rule. The template allowed a dated claim without a source next to it. So the correction was typed as a repeated failure or risk, routed to our rules, with the retraction itself as the evidence:
Every dated fact in any brief carries its source inline, and the year gets verified. A weekly edition never invents an account.
That rule now lives in the process that produces the brief, in the template every future edition is built from, and in the Recommendation Standard's own evidence requirement. A brief drafted in September inherits the rule without anyone having seen the July retraction, and if a draft breaks it, the check catches it before a person ever sees the draft.
What made it a correction rather than a private fix: it had a destination, an approver, evidence, and it changed something beyond the one document it started in.
What the standard shares with its sibling
One standard governs what goes out: the Recommendation Standard, seven parts, always, reviewed and signed by a person. This one governs what comes back. Together they close the loop: a recommendation is issued, the business responds to it, and whatever that response teaches us is routed, evidenced, and kept for the next one.