Support and help

The confidence is the weakest link in the chain, not an average. A value read from three documents is as good as the worst of the three readings; averaging would let two good readings hide one bad one.

A reading cannot be more trustworthy than the method that produced it. A tag from a scan is held below a tag from a text layer, and a text layer only says which characters are present - not that they were read correctly in context.

The confidence ceiling is a property of the method, not of the document. OCR cannot exceed what the engine has been measured at, and raster symbol recognition is capped at 60%: a symbol recognised from pixels cannot be more certain than the pixels allow.

These ceilings are limits, not measurements: nothing a method produces may exceed what that method can support, and a reading sitting at the ceiling is still unverified.

A confidence is never reported against a human decision. A placement somebody recorded is not a reading and has nothing to be confident about.

Requeuing a document measured as unreadable is refused: reading it again produces the same refusal, and a retry that cannot work tells the user the problem is theirs to wait out when it is not. A refusal states what is wrong with the file rather than reporting an empty result as a successful read.

Changing the class of a document that has already been read is refused, because everything extracted from it belongs to the old reading. Correct the class and reprocess deliberately.

A document register exists to record what was issued. Dropping an issue because the file is missing would hide the gap rather than report it, so the revision appears in the history with no file against it.

A comparison may be made between any two revisions, not only consecutive ones. A tag deleted at one issue and reinstated at the next is unchanged between the ends, and adding up the steps would report it as two changes when the project sees none.

Anything still citing a superseded revision is citing something no longer drawn.

Where two documents disagree about an attribute, neither value is presented as the answer and the row cannot be verified until somebody decides which document is right.

A tag whose value two documents dispute cannot be verified: the question is which document is right, and that is a different decision, taken on the reconciliation page. Verifying it in the register would record an agreement that does not exist.

Deciding a conflict means naming the document that governs and why it does. The basis is required and must say more than the decision itself: it is what the next person reads when they ask how the question was settled.

A boundary needs a defining document and a basis. Confirming one while a disagreement about it is open is refused, because it would settle the disagreement silently.

A document that passes every stage produces readings, not facts. The registers it fills are marked unverified until a person has checked them against the source.

Verification is a person saying they checked the record against the source. It is recorded against them by name, and a disputed value cannot be verified at all.

The verification queue is ordered by consequence, not by confidence: a relief valve read at 0.9 matters more than a cable read at 0.4. It is assembled from the project's records rather than from notifications, because a queue built from notifications shows what you were told about rather than what is outstanding.

A test pack that spans two units is ordinary: a utility tie-in is tested with the utility, not with the unit it serves. A single tree cannot express that, and merging the hierarchies would mean choosing one - which is how a commissioning sequence comes to be driven by a physical breakdown that was never meant to carry it. Several hierarchies are active at once instead.

A node in the commissioning hierarchy is a decision somebody recorded. A dashed box on a drawing is a drafter's annotation. EDS never promotes the second into the first: a drawn boundary is never an approved system boundary.

Nothing is inferred from lines meeting on a sheet: two lines crossing a P&ID are usually not joined, and a model built from crossings is one in which everything connects to everything.

A continuation reference - the drafter stating that a line carries on to another sheet - is the strongest of the relationship kinds, and still a statement rather than a verified connection.

A shared asset is the weakest: two sheets drawing the same pump does not make the sheets adjacent, and often means one is a detail of the other.

An edge drawn from a reading can be wrong because the reading was wrong. An edge drawn from a decision can be wrong because somebody was. Only the first is fixable by reprocessing.

A requirement is attached to a tag only where it names the tag. One that governs it without naming it cannot be found this way, and guessing would attach clauses to items they do not govern.

An obligation that reads as more than one kind of requirement - a quality requirement or an inspection requirement, say - stays unconfirmed until somebody decides which, and says why. Turning it into a requirement first would put a requirement into a deliverable that the contract may not contain.

Accepting a model's suggestion needs a basis naming the clause it rests on. A requirement whose source document the project does not hold cannot be accepted at all.

While a conflict between two requirements is open, neither is applicable, nothing may cite either as the governing one, and a deliverable that depends on them cannot be approved.

Precedence between documents is itself a term of the contract. EDS never applies an order of precedence without somebody recording that it is what this contract says.

Where a specification has produced few requirements from many pages, the rest of the document has not been turned into anything. That is a fact about how far extraction has got, not a statement that the remaining pages contain no obligations.

The author may not be the checker or the approver. That separation is enforced in the page, in the write service and in the database.

An organisation owner or administrator can change settings and read the audit trail. They cannot approve a hydrotest procedure unless somebody granted them the approval capability on that project, by name and with a recorded reason.

An approval statement is an attestation and is recorded verbatim against the person who makes it. It must say what was checked and by whom.

Returning a deliverable raises a new revision. Returning an approved deliverable means withdrawing the approval first, which is a separate, recorded act.

Granting approval or issue authority asks for a reason. Granting a viewer does not: demanding a justification for every addition trains people to type 'because' into the box, which costs the record the reasons that matter.

A document received for construction with no approver recorded is either a record-keeping gap or a document control failure, and the register cannot tell which from the record alone.

An open blocking comment stops approval. It does not stop drafting or reviewing, so work continues around it - and it cannot be downgraded to get past the gate, because the reviewer who raised it is the only person who may close it.

Required inputs are checked against the project's records each time the page is rendered. A deliverable can still be drafted while any of them is open; the gap appears in the draft where the value would have been.

Generation states the gap in place of a value, with the reason, and writes the rest of the section from the evidence that is available. A missing pressure basis is a recorded gap that blocks approval, not a plausible number.

A figure is produced as a placeholder with its caption and its source named. EDS does not draw an isolation schematic: a marked-up drawing that looks like an engineering deliverable, produced without an engineer, is worse than an honest placeholder.

A document control block with a blank approver is a draft, and EDS will not render a watermark-free cover page for one. An unapproved deliverable that looks issued is the document control failure the application exists to prevent.

Section numbering is generated from the structure, so a section inserted in the middle renumbers everything after it and the contents page follows. A placeholder that no record satisfies is left in place and reported, rather than being quietly dropped.

With no mark supplied, documents are produced with the project name and no logo. The cover states that no logo was supplied rather than showing a placeholder image, which in a document issued to a client reads as a production fault.

The project code is part of every document number already issued, so changing it would mean renumbering everything the project has issued.

Who may approve is a capability granted per person on the team page, not a project-wide setting.

Confidence ceilings are properties of the reading methods, not preferences: raising one would not make a scan easier to read.

Naming conventions change how documents are read. A change applies to documents processed afterwards; everything already extracted keeps the convention it was read under until it is reprocessed.

The organisation slug appears in every storage key. Changing it after files exist would orphan all of them, so a change is refused once an object exists under it.

Support access is off by default. A grant is capped at twenty-four hours, permits reading only, and appears in your audit trail under the name of the person who used it.

An invitation grants organisation membership and no project access. Project capabilities are granted per project, with a recorded reason.

An allowance of zero against a service nobody switched on is not a customer using none of their quota. It is a quota that does not exist, and the difference decides whether anybody should be chasing it.

OCR and AI counters read zero because no provider has been activated, and storage reads zero because no storage bucket has been reachable.

Files the platform generated for its own reference project are not chargeable: counting them as customer storage would inflate a bill nobody owes.

An import can overwrite dates somebody changed in EDS, so it asks. A schedule import is a statement about the plan, not about the work.

Where nothing in the imported schedule names a test pack, no link exists and the mapping is chosen on import rather than guessed.