Methodology
How a BiP Omega screen is built
The screening is a disciplined, repeatable process applied to a project file. This page describes what the method does and how it protects a conclusion from narrative bias. It does not publish the proprietary requirements catalogue itself.
Evidence provenance
Every value the screen relies on is tied to a source document and carries an explicit confidence classification. A value that only appears in a developer or supplier statement is recorded as an assertion, not a confirmed fact. A manually entered value with no source cannot be classified as confirmed.
Configuration matching
The screen first fixes the declared configuration — capacity, chemistry, container, thermal basis. Everything else is assessed against that configuration. If the file describes a different product than the one being priced, that mismatch is itself a finding.
Applicability
A fixed catalogue of technical requirements is filtered to those relevant to the declared configuration and jurisdiction. Requirements that do not apply are recorded as not-applicable with the reason — they are not silently dropped.
Requirements-based screening
Each applicable requirement is dispositioned against the evidence: satisfied, partially satisfied, a material gap, contradicted, or not reviewable. The disposition is a function of the documents, not of a narrative or a keyword count.
Non-compensatory critical gates
The screening verdict is the worst applicable gate outcome. There is no weighted average and no scoring model. A domain being clear can never numerically offset a decision-critical gap elsewhere. A NO-GO is harder to reach than a material gap — it requires an analyst-confirmed criterion that cannot be met in the current configuration.
Contradiction handling
Documents that disagree on a material point are registered as first-class contradictions. A material contradiction is only resolved by a named person, with a reason and a supporting document — never silently, and never by an automated step. Unresolved material contradictions are disclosed in the report.
Bounded calculations
Where a bounded, fully-provenanced calculation supports a screening judgement (for example an ambient-exceedance check), it is computed with an established method, every input and assumption is stated, and it abstains when an input is missing. These calculations are decision support only — they are never a verdict input.
Human review
A human analyst reviews the completed assessment against an attestation checklist — scope, evidence cut-off, material gaps, contradictions, specialist escalations, the verdict, and report traceability — and signs the screening. No client deliverable is released without a sign-off that matches the assessment inputs.
Traceability
Every material conclusion in the report traces from the verdict to the technical requirement to the evidence item to the source document. A separate traceability appendix records this mapping. A conclusion the evidence cannot fully support is downgraded, not asserted.
Report binding
The report is a deterministic function of a single canonical data file — the same evidence produces the same report, byte-for-byte, on one toolchain. A manifest binds the report to its evidence set, its cut-off date, and the methodology versions used.
On validation
The method's software and process are verified — continuous integration, deterministic behaviour, adversarial and security testing, and fail-closed controls. Its predictive performance has not yet been established through a completed prospective track record of screening positions resolved against real outcomes, and no accuracy figure is claimed.
Verification & validation status in full →