Frequently asked questions.

Every finding carries a citation to the requirement it was reviewed against and the drawing, model or document it was found in, so each one can be checked at source rather than taken on trust. Where the evidence does not settle a finding, Tektome does not resolve it. The item is referred to a named person and recorded as referred, and that person's decision is what closes it.

No. Tektome produces the review position and the evidence behind it. A named professional still makes the judgement calls and still signs. Items the evidence cannot settle on its own are referred to a person by name rather than closed automatically. What the record holds is who examined what, when, why it was accepted, and what was left to human judgement.

Project data stays with the firm and is never used to train shared models. Tektome holds ISO/IEC 27001:2022 certification and SOC 2 Type II attestation. Data residency is arranged with each customer rather than fixed to a single region. On a pilot engagement, everything is deleted at close.

No migration. Packages are submitted as they are, through direct upload, a Revit plugin or the public API, so drawings, models, specifications and correspondence stay where they are. Document connectors for Box, SharePoint, Notion and Slack are on the roadmap, and we are continually adding more. Nobody has to re-key a status into a fourth tool for someone else's audit trail.

The requirement register is built from the project's own documents, so the inputs are the contract, the brief, the Employer's Requirements, the standards that apply and the correspondence already on file. Tektome ships with more than 50 review templates, extended with the firm's own requirements, workflows and standards, so the starting point is not a blank rulebook. How long it takes depends on the firm, since the standards in play and the way each one works differ.

Yes. By default, we operate securely on the cloud (Microsoft Azure). For clients with strict data requirements, we offer private cloud or on-premise deployment options, keeping AI models up to date.

We are specialised in working with AEC files like PDFs, DOCs, Images and Spreadsheets and certain BIM files.

Tektome optimises your AEC data through pre-processing (for structure) and post-processing (for accuracy), while maintaining strict data isolation. Unlike public AI systems, we do not fine-tune on your data, ensuring privacy and eliminating hallucinations.

No, we are proudly self-funded. Our team has already launched successful products in the market that generate sustainable revenue, allowing us to grow independently without relying on venture capital. This gives us the freedom to focus on long-term value and product excellence without external pressures.

We take data security extremely seriously. Our operations are governed by industry-leading standards, including ISO/IEC 27001:2022 for information security management and AICPA SOC (System and Organization Controls) compliance. These certifications reflect our rigorous commitment to safeguarding customer data through structured risk management, access controls, continuous monitoring, and secure operational practices. Whether you’re interacting with our team or using any of our solutions, your data is protected by robust, independently-audited security frameworks.

No. Your company data remains private and siloed. We do not use client data for model training, and each customer’s environment is fully segregated for security.

Yes. Tektome is built with enterprise-grade security as a core principle. We are certified under ISO/IEC 27001:2022 and AICPA SOC, ensuring our platform follows globally recognized standards for data confidentiality, integrity, and availability. This includes encrypted data storage and transmission, secure access protocols, continuous compliance monitoring, and regular audits. Whether you are reviewing a package, collaborating with stakeholders, or exporting reports, your data is protected every step of the way.

Review coverage is the share of a scheme's requirements that have actually been reviewed, and it is the thing most review reports cannot report. A findings list speaks only about what it opened, so a requirement nobody examined and a requirement that passed read identically at sign-off. Coverage measures the difference: for every requirement, whether it was reviewed, and with what result.

Only by holding a register of every requirement the scheme has to satisfy, then reporting status against all of them. Tektome maintains that register from statute through to company standard, and surfaces the requirements nothing has been reviewed against as a ranked list before sign-off. They are ranked by what rests on them, so a critical unexamined item does not sit below forty trivial ones.

Insurer proposal forms now ask by name about milestone reviews and design gateways, so the answer has to be a described process and the record that shows it ran. A reasonable-steps defence is only as good as that record. Tektome produces it as a by-product of the review itself, rather than as a write-up assembled shortly before renewal.

Long enough to answer a claim, which can arrive decades after the project team has dispersed. A Principal Designer or Principal Contractor duty runs for as long as the liability does, and it is answered by whoever can produce the record. Tektome links every requirement to its source and every decision to the person who took it, and holds that for as long as the duty lasts.

Because compliance review, coordination review and submittal QA each produce their own findings, and held separately none of them says where the scheme stands. Risk that sits between two review types is the risk nobody owns. Tektome feeds every review into one consolidated position per scheme, which is the only place a between-the-gaps issue becomes visible.

Yes, with an important distinction. Rule-based checkers test the slice of code somebody encoded, against the model. Tektome extracts the requirements from the approved documents, standards, planning conditions and client papers that govern the specific scheme, then reviews drawings, models, specifications, schedules and calculations against all of them on every issue, with the clause cited behind each finding.

Around 40% of Gateway 2 applications are rejected at initial validation, and roughly 35% are turned back for missing information rather than bad design, according to reported Building Safety Regulator statements. Median approval is running at 22 weeks against a 12 week statutory target. Tektome shows what would turn a submission back while it can still be fixed. No promise about approval times, only about knowing before you submit.

Requirements are extracted from whichever documents govern the scheme, rather than from a fixed encoded rule set. That covers approved documents and national codes, British and European standards, local planning conditions, Employer's Requirements and the client's own technical standards. Because the register is built from the project's own governing documents, the approach is not tied to a single jurisdiction.

Yes, and this is usually where the exposure sits. House standards, Employer's Requirements, client briefs, planning conditions and the commitments made in minutes and correspondence are reviewed alongside statute, each carrying its own status. A rule-based tool holds none of these, because they were never published as code and never encoded as rules.

Both, and it has to. A clause is usually satisfied across several artefacts at once: drawn on a sheet, dimensioned in a model, described in a specification, quantified in a schedule. Tektome reads IFC and native models, PDF and DXF drawing sets, specifications, reports and calculations together, and against each other. Review only the model and everything outside it goes unexamined while reading as clean.

Clash detection reports where two solids intersect. Coordination validation asks whether the coordinated design still satisfies what was agreed, across the drawing, the model, the specification and the incoming submittal at once. A riser specified at 1000mm and modelled at 800mm produces no clash, because nothing intersects. Geometric clash is largely solved. The disagreement between formats is not.

The ones that reach site. A specification that says something different from the drawing. A fabricator delivering to the model rather than the intent. A design change that broke a requirement agreed in a meeting four months earlier. None of these intersect anything, and requirements that live in correspondence are invisible to a geometric review, so nothing in the process was looking for them.

By reviewing each against the requirement it has to satisfy, then against the other accounts of the same element. Drawing against specification, specification against schedule, schedule against model. Tektome surfaces the disagreement rather than assuming it away. Most coordination failures are contradictions between formats, not intersections within one of them.

No. Geometric review still runs, alongside setting-out alignment and model data quality validation. What changes is the triage: conflicts are ranked by the requirement they threaten rather than presented as an undifferentiated list, with model data quality separated out rather than buried in the same queue. Finding intersections is mature and widely available, and Tektome is not trying to win on it.

Against the requirements they have to satisfy, before they are accepted rather than on receipt. A submission accepted on arrival transfers the error into fabrication, where it stops being a drawing problem. Where a fabricator has taken a dimension from the model instead of the specification, the submittal is returned with comments before release, not discovered at delivery.

A deliverables schedule records that something arrived. It cannot say whether what arrived satisfies the brief, whether anyone reviewed it, or who owns the half that is missing. Tektome holds every deliverable against the requirements it exists to satisfy, so "delivered" means reviewed and conformant. That is the only version of delivered a programme can safely be built on.

By reading the meeting rather than waiting for someone to re-key it. Minutes are read and the actions, decisions and revised dates inside them are pulled straight into the tracker, alongside the latest issue. Most trackers are accurate on the day they are updated and wrong every other day, because status is re-typed by hand in the week of a report.

Yes. Deliverables are held against the brief, the Employer's Information Requirements and the programme, which are the documents that define the obligation, rather than against a list somebody typed at the start of the job. A deliverables list drifts from the brief the moment either one changes, so holding them together is what keeps the tracker true.

It is named as unowned, rather than left to be discovered when it fails to arrive. An item sitting between two parties that neither has claimed is not a tracking problem. It is the one nobody is going to produce. Tektome carries a named owner on every requirement and deliverable, and states explicitly where there is none.

By carrying a forecast beside every due date, so drift is visible while there is still float to absorb it. Incompleteness counts as lateness, because a package arriving without half its content has not really arrived. The window in which a slip is cheap to fix closes long before the slip appears in a monthly report.

By reading the correspondence they arrive in. Meeting notes, emails, reports and memos are scanned for changes the client or team has asked for, and any never raised against the Employer's Requirements or the brief are flagged with the document and date that carries them. An instruction that arrives in a sentence is still an instruction, and built without being priced it is margin given away.

By running the proposal against the requirement register first. What it touches, what it undoes and what it puts at risk are stated before any modelling effort is committed, so testing a change costs a question rather than a week. The point of maximum influence over a change is before the team has invested in making it work.

That a saving reappears later as rework, in which case it was never a saving but a deferred cost at a worse exchange rate. Each proposal is set against the settled requirements it would break, flagged at the point of decision rather than found in a later review. On a real sequence, a cladding substitution undid two settled requirements and surfaced as a claim 22 weeks later.

Drift is a settled requirement being quietly moved by a sequence of small decisions, each defensible on its own. Tektome keeps every value a requirement has held, with the decision and the person behind it, so a later change reads as a reversal of something agreed rather than as a fresh position. A value engineering change in August will not know what was settled in June. The register does.

What changed, when, who asked for it, what it affected and what was decided, all linked at the time. Disputed costs run at around 33% of contract budget, according to HKA's CRUX report to July 2025. Tektome assembles the bundle from the live record rather than from an email archive under time pressure months afterwards.

Design maturity is how much of the design is settled enough to bear a commitment, measured against a named gate rather than judged from how the drawings look. Tektome reports what is settled, what is still open and what cannot yet be reviewed because the design is not developed that far, against what that specific gate requires.

By measuring it against what fixing a contract sum requires, item by item. A scheme can be ready for approval submission and not ready to price, on the same day, from the same drawings. Where readiness falls short of what the gate requires, the shortfall is itemised rather than summarised, so effort goes to the items that move the position.

Because each gate bears a different decision, so a single readiness figure across the whole project answers no actual question. Approval submission, tender, contract sum and issue for construction each require something different from the same design. Readiness only means something when it is measured against a named commitment.

Information that looks provisional rather than committed is put forward as a proposal, and a person confirms it before it counts toward readiness. A round figure, an item marked TBC or a value unchanged since concept reads exactly like a decision, which is what makes a placeholder the most dangerous thing at a gate. Presence and resolution are established. Provisional against fixed is a suggestion for review.

That is often the commercial reality, and it can be the right call. What is never right is doing it without knowing which parts are unresolved. Tektome states what can and cannot bear the decision, and where the commitment is made anyway, the record shows what was known to be open at the time and who accepted it.