LintaraDocument control, progress and cost for industrial projects
Every deliverable, accounted for.
The documents, the owner's answers, the progress and the payment, kept on one record the whole project team can trust. Beside the owner's system, not instead of it.
Demo: a sample water treatment project, nothing is saved. The application is in private preview.
DocumentP-501A pump, general arrangement · Rev 0
ContractorYSV-MEC-VGA-50013
OwnerYV. 5.02 3.7820
VendorKSB xP501A.GA. 3842
StageApproved for manufacturing
Last answerCode 1, owner transmittal YWA-TRN-000412
Earns100% of its 20 h weight · system 500, mechanical
One document, three numbers, its own stage and its full in-and-out history. Progress is calculated from records like this, never typed in.
The problem
Your project's truth lives in too many places.
The MDR spreadsheet
Ours, theirs and the vendor's numbers in different columns. Correct on the day someone last updated it.
The owner's portal
Review codes come back in the owner's system. Someone retypes them, line by line, into the register.
The schedule
Progress is a percentage someone types into P6. Nobody can show which documents earned it.
The inbox
What went out, to whom and when it is due back lives in sent folders and transmittal PDFs.
Four places, four versions of progress. One record, traceable to a document.
What's inside
The chain from document to payment, on one record.
Each card says where it stands today: in the application, in the demo, or being built.
In the app
One document, three numbers
Owner, contractor and vendor numbers on the same record, each checked against the project's number formats. Owner returns match by any of them.
In the app
Your project's lifecycle
Your own stages, from drafts to as-built, with their progress credit. The document index shows planned against reached for every stage.
In the app
Owner returns without retyping
Read the register, transmittals and review results exported from twelve systems, Aconex, ProjectWise, AVEVA, SharePoint, ACC and Procore among them, as Excel or CSV. See every match before anything changes; only clean lines apply.
In the app
Every transmittal, in and out
One log with purpose, recipient and the date an answer is due. Every document keeps its own history of what came and went.
In the app
Reviews and the comment sheet
Parallel and serial reviewers, private drafts until a reviewer finishes, "no comment" by name, answers and closure that carry from revision to revision, and the CRS in and out of Excel.
In the app
Progress you can trace
Engineering progress from document stages and your rules of credit, rolled up by system and discipline, with versioned rules of credit for documents and site items, the S-curve, P6 or MS Project schedules linked by Activity ID, the DCMA 14 check, and progress sent back to P6. Cost-based earned value (CPI, EAC) is in the demo.
In the app
Progress payments
A draft payment application from the same records and the contract register, with variations in the contract value, the FIDIC Interim Statement in 14.3 order, and the Turkish hakediş set: taxes and deductions, the advance ledger, cover and report, in Excel and PDF, checked before issue.
In the app
Handover and assets
Tags linked to their documents and equipment, checked for completeness before the owner sees the handover package.
In the app
Plant data, read only
OPC UA and historian values beside the asset record. Read only: no command goes to the plant.
In the app
Built for a project team
Project roles, two-step sign-in and single sign-on, an audit trail of every change. Owner, subcontractor and vendor people join free and act on what is theirs: vendors submit, the owner reviews.
In the app
Project mail as evidence
Drop a saved e-mail or copy the project address. The original is kept unchanged with its times and sender check, then filed as a letter, an RFI answer or a transmittal.
In the app
Search inside the files
The words in PDF, Word and Excel files and in scanned pages, read in Turkish and English. A result opens on the page it is on.
In the app
Meet Linto, the help that lives in the project.
A small site robot in the corner of every page. It knows which project and which document you have open, answers from the record, and never sends or approves anything on its own.
Ask the project
"What is late with the owner?" Counts, lists and status come straight from the register. Other questions get an answer that cites its records, when you switch the AI on.
Show me
Short guides for every page in English and Turkish, and tours that light up the real buttons one step at a time.
Report a problem
The screenshot, the page and the record are attached for you. You follow the answer on the same report.
Who it is for
Built for the people who keep the record.
Document control
- The register, not a spreadsheet
- Import the MDR you have; numbers, stages and roles are checked on the way in and reported, never silently dropped.
- Owner returns in minutes
- Drop the owner's export in, review the matches, apply. Mismatched revisions and unknown numbers stay flagged until someone decides.
- Nothing slips past a due date
- Every transmittal carries its purpose and response date; overdue answers stand out in the log.
Project controls
- Progress you can defend
- Every percent traces to a document and a rule of credit agreed with the owner, not to a judgement made on Friday afternoon.
- Plan against reached
- Planned dates per stage from the index, compared with where each document really is.
- From progress to payment
- The same records feed earned value and the draft payment application.
The project director
- One answer to "where are we?"
- Progress by system and discipline, what is waiting on the owner and for how long.
- Start small
- One work package, a 12-week pilot, measured against your own figures before anything is decided.
The owner's handover team
- Handover data that arrives complete
- Tags, documents and equipment checked against the owner's own rules before the package is sent.
- Your numbers, your codes
- The contractor works in your numbering and your review codes; you keep your own system.
Why Lintara
Eight questions to ask before you choose.
Most projects run on spreadsheets beside the owner's portal; large ones also buy an enterprise suite. Lintara sits beside the owner's system and keeps the contractor's record whole.
| The question | Spreadsheets, e-mail and the owner's portal | Enterprise suites | Lintara |
|---|---|---|---|
| Owner, contractor and vendor numbers on one document | PartlyThree columns, kept in step by hand | PartlyOften one number per document, others as free text | YesThree numbers on one record, each with its own format check |
| The owner's review results land without retyping | NoRead in the portal, typed into the register | PartlyInside one system; across two systems, by hand or a paid integration | YesReads the owner's export, matches by any number, shows every match first |
| Stages and review codes as the project defines them | YesAnything goes, and nothing is checked | PartlyConfigurable, often by the vendor's consultants | YesStage table, review codes, roles and number formats are project settings |
| Progress you can trace to a document | NoA percentage typed into the schedule | PartlyUsually a separate project-controls product | YesFrom document stages and your rules of credit, rolled up by system and discipline |
| Every transmittal in and out, with the date an answer is due | PartlySent folders and PDF transmittals | YesUsually the core of the product | YesOne log, with purpose, recipient and overdue answers flagged |
| Works beside the owner's system | YesBy copying from it | PartlyBuilt to be the project's system of record | YesReads the owner's exports; writes nothing to the owner's system |
| The owner, subcontractors and vendors join at no cost | YesEveryone already has e-mail | PartlyOften counted as named users | YesPaid per project; external participants are free and unlimited |
| You can start on one work package this month | YesIt is what you have | NoUsually an implementation project | YesA 12-week pilot on one package; a demo to try today |
The middle column describes enterprise CDE and project-controls suites as a category, not any one product.
Compare all features (223)
In the app works today
Partly in the app works today, with what is not built yet said on the line
In the demo shown on sample data
Phase 1 being built, then phases 2 and 3
★ where we differ
Documents · 42
| One document, several numbers (employer, contractor, supplier) ★Keeps the employer, contractor, supplier, sub-supplier, file or CAD and legacy numbers on one document, each with who assigned it and when, marks the one printed on the document face, and checks each type against its own numbering mask, including a regular expression for dotted or variable-length numbers. The project chooses which numbers the document's cover sheet and the issue stamp print, and can make a number kind mandatory for a document class (checked on entry, in a grid, in an edit and on a supplier upload, and reported on import). | Rare In enterprise suites | In the app |
| Document index set up at project startBuilds the planned document list up front, with planned and actual dates per stage. Planned dates are typed stage by stage or filled from one planned first issue date with the project's stage durations; planned against reached stays computed, cancelled documents are not counted, and the planned dates of a document that is behind plan open and can be corrected from the index. The index grows as the project goes: planned rows are added in bulk from a number pattern, each with its own audit entry, and the growth against the first index is counted beside plan against actual. | Common In enterprise suites | In the app |
| Classification references: CSI MasterFormat, RICS NRM, WBSA new project starts with CSI MasterFormat, the default for industrial projects (documents and cost codes, the edition left for the project to state, marked example rows, not required before a formal issue); RICS NRM is a choice. Classifies a document, a BoQ line and a cost code by the work result (CSI MasterFormat with the edition the project adopted, RICS NRM 1, 2 or 3, or the project's own list; up to two, for example MasterFormat for specifications and NRM 2 for the BoQ, or none) and by WBS element, with a primary reference and additional ones for multi-scope records. The references are links, never part of the number, so changing one never changes a document number. Both standards are licensed, so the project imports its own edition from Excel (code, title, parent) and only a few marked example rows ship. A code where only the division is known is marked provisional and completed before a formal issue (off, warn or block, a project setting); not applicable is a value written with its reason, never a made-up code. A document with a WBS shows the discipline and document type codes the WBS table suggests (a hint, never forced). The choice changes in one step, before or after references are written: references of a classification taken away are kept and flagged, never deleted. Projects opened before the default keep what they have. The register searches, filters and groups by code, one code finds documents, BoQ lines and cost codes together, and the MDR export carries primary and additional references. | Rare | In the app |
| Project-specific document stages and credit ★Lets each project define its own stages (draft rounds, engineering approval, manufacturing approval, as-built) and the credit each one earns. | Rare In enterprise suites | In the app |
| Project-specific document rolesAssigns preparer, checker, approver and reviewer roles per project, with role titles the company can rename. | Common In enterprise suites | In the app |
| Transmittal log for incoming and outgoing documentsRecords every document sent or received with direction, purpose and reply due date. The recipient of an outgoing transmittal confirms receipt from a link that needs no account, or a person records the confirmation with its date; an incoming transmittal is recorded straight from an inbox e-mail. | Expected by buyers In enterprise suites | In the app |
| Master document register (MDR)Holds the master list of all project documents and their status, filled by import or by hand. A new document is entered on a form, its number typed or built from the project's number mask with the next free sequence; a duplicate or a number that breaks the mask is refused with the reason in both languages. Rows pasted from Excel are checked one by one and added on confirmation, every field including the planned dates is edited in the document drawer with the change shown in its history, a changed number keeps the old one findable, a selection is changed in bulk (planned dates move by working days on the project calendar), and a document is cancelled with a reason and reinstated rather than deleted; only one never issued is deleted, by an administrator with a fresh code. | Expected by buyers In enterprise suites | In the app |
| Revision and version historyKeeps every revision and version of a document. | Expected by buyers In enterprise suites | In the app |
| Files on document revisionsAttaches PDF, native CAD, Office and image files to a revision, stored once by SHA-256 and never overwritten, with earlier revisions' files listed, downloads for project members and PDF preview in the browser. Every file is scanned for viruses as it comes in (ClamAV, a separate service of the install package); a file with a virus is refused and nothing is stored.Not yet: Downloading several files as one ZIP is not built. The virus scanner has not been run on a real server; the tests give it a stand-in daemon that speaks the ClamAV protocol. | Expected by buyers In enterprise suites | In the app |
| Outgoing transmittalsSends a set of documents, with the current files of each, to a recipient with a formal transmittal record and a printable cover (Excel and PDF). | Expected by buyers In enterprise suites | In the app |
| Multi-step review workflows with templatesWorkflow templates per project: which documents each fits (discipline, type, originator, number mask, first match wins, with a default), the steps with the people or the project role that does each one and the working days allowed, parallel or in sequence. Uploading a file starts the review from the template that fits and makes the next revision when needed; an approval hands on to the next step, a return with comments sends the document back to the preparer as a new revision, and the last approval can draft a transmittal to the owner. Each round records the template and version it started from. | Expected by buyers In enterprise suites | In the app |
| My tasks and where a document isA page and a count in the menu with every step waiting on you (document, revision, step, due date, working days late) and an e-mail when a step becomes yours. The register and the document drawer show the running step, who holds it and since when; the project overview counts documents in internal review, late steps and documents ready to issue. | Expected by buyers In enterprise suites | In the app |
| Review rounds, comment resolution and deadline engine ★Review rounds with parallel and serial steps, private reviewer drafts, named "no comment", answers and closure, an Excel CRS round trip, and a contract clock per review kind in working or calendar days with reminders, a banner of what the contract deems when the period ends (never an automatic approval) and a time to resubmit. | Rare In enterprise suites | In the app |
| Submission record and approval clock for construction drawings ★Tracks each submission to the employer, the one-month approval period and the status, and warns when the period lapses or work starts in an unapproved area. For a Turkish public works contract, each application project the contractor prepares is recorded with its documents, sections, the areas and systems it covers, the day sent and the transmittal. The one-month answer period counts from the day sent (or the period the contract gives, with its clause) and the days left or past are shown; the owner's answer, typed in by a person, stops the clock: approved, approved subject to later changes, or returned with reasons, and a returned project is resubmitted with a link back. When the period passes without an answer the page says the contractor may claim an equal extension of time, with the days counted; it is not legal advice and the contract's own clause decides. Diary lines, inspections and the phone entry on an area or system whose project is not approved get a warning, and the project overview counts them. A draft letter to the owner listing the overdue submissions is ready in Turkish and English; the application never sends it. Not covered: a reminder by e-mail before the due day, the day the owner registered the submission as the start of the clock, and the effect of the extension on the programme. | Not found elsewhere | In the app |
| Subcontractor register with approval and share limitsKeeps each subcontractor with its scope and the subcontract it is let under (once linked to the commitment on the cost page its value is the value), the employer's approval (asked, approved with its day and the number of the employer's letter, or refused with the reason; a refusal can be asked again and an approval stays), the day the subcontract was signed and the day its copy went to the employer, and the signed subcontract and the stamp tax evidence as files; what is missing is written on the row. Shows each company's share and all together's of the current contract value against the limits, subcontracts not in the register included; the limits are project settings, by default one subcontractor 30% and all together 50% unless the tender says otherwise, and every screen says to check against the contract. A new or changed subcontract that would pass a limit gets a warning that does not stop it. A subcontractor's people can be invited as external participants only once the employer's approval is recorded (the project administrator can relax this by writing a reason, which stays in the audit trail), and a site diary or phone entry that names a subcontractor without approval warns. A subcontractor's person sees only their own company's row and approval state, never another subcontractor's value or share. Not covered: an approval that lapses, a limit by kind of work, the employer's people approving in the app, and the stamp tax amount as data. | Not found elsewhere | In the app |
| Online markup on the file under reviewA PDF viewer on the review page (in the browser, nothing from a CDN) with page thumbnails and zoom, usable with a finger or a pen on a tablet. Tools: a pin with a comment, a rectangle, a cloud, a highlight and free text. Each markup is a comment of the review round with its page and its place on it, so it appears in the comment resolution sheet, Excel included, and a click on a sheet line jumps to its place. A draft until the step is finished; later steps see earlier markups. Word and Excel files are shown through a PDF made once on the server with LibreOffice; native CAD (DWG, DGN) downloads, and the PDF the author uploaded next to it is reviewed. Not covered: markup of CAD files in the browser and comparing two revisions. | Expected by buyers In enterprise suites | In the app |
| Commented copies and what comes back to the preparerA reviewer attaches their own commented file (PDF, Word, Excel) to their step, instead of or next to markups; it is listed on the round with the step and the reviewer. A step may be finished with only a copy: the sheet then has one line that points at it. When a round returns, the preparer sees every markup and attached copy in one place and answers each comment by the usual rules; the next revision's review shows which earlier comments it claims to close. | Expected by buyers In enterprise suites | In the app |
| Stamp on issueA project setting, off by default: the PDF that leaves in an outgoing transmittal carries a stamp with the document number, revision, the owner's return code when there is one and the date. The upload stays untouched; the stamped copy is a file of its own. | Rare | In the app |
| Technical queries and RFILogs and tracks technical queries and requests for information. | Expected by buyers In enterprise suites | In the app |
| Correspondence registerRecords letters and other correspondence against the project. | Expected by buyers In enterprise suites | In the app |
| Email intake: project address and drag-and-drop ★Gives each project its own receiving email address (once a mail provider is set up on the server) and accepts dropped .eml and .msg files, without access to anyone's mailbox unless the customer switches on a mailbox connector (see the next steps).Not yet: Only Postmark's webhook has an adapter; Mailgun and SES are not built because each needs the provider's real sample payload. | Rare | In the app |
| Sent, received and recorded times kept as three fixed fields ★Stores when a document was sent, received and recorded as three separate fields that cannot be changed. | Rare | In the app |
| Sender allow list, screening queue and visible email authentication resultsAccepts email only from approved senders, holds the rest in a screening queue, and shows SPF, DKIM and DMARC results. | Not found elsewhere | In the app |
| Email as evidence: immutable raw message and evidence pack ★Stores the raw email unchanged with its hashes and checks its DKIM signatures the day it arrives, keeping the key record as fetched. From one message, a thread, a selection or the mail linked to a claim it exports a zip: the unchanged .eml files, the attachments, a JSON and a printable manifest with every SHA-256, the times and the DKIM result, and who took it and when. A pack or an .eml that comes back is checked against the manifest and the stored bytes. An optional RFC 3161 time stamp, off by default, stamps only the manifest's hash. It starts a proof trail but does not replace a formal notice. | Not found elsewhere | In the app |
| Outlook add-in: send the open message to the project InboxOne button in Outlook (on the web, the new Outlook and the desktop) sends the open message to the Inbox of a project, kept unchanged as evidence with its hash and marked as filed from Outlook by that person, and can file it at once as a letter, an RFI answer or an incoming transmittal with the Inbox's own preview. It reads only the open message, asks for the least Outlook permission and no Microsoft Graph consent; your Microsoft 365 administrator deploys it from a manifest the server makes from its own address. Not yet tried in a real Outlook. | Rare | In the app |
| Email next steps: shared mailbox, registered email, notice clockAn optional shared mailbox connector (Microsoft Graph, read only, limited to one mailbox by the customer's Exchange RBAC, off until an administrator switches it on after a connection test that tries a second mailbox), a registered-email (KEP) connector that takes dropped .eml files, and notice detection that marks mails that read like a contractual notice and proposes a time-bar clock (not legal advice).Not yet: Not built: reading a KEP provider's own API (no provider is named yet), Graph change notifications (the timer polls) and the check of a KEP provider's signature. Nothing has run against a real Microsoft 365 tenant or a real KEP provider: the tests use stand-ins. | Rare | In the app |
| Immutable audit trailRecords every change in a log that the application's own database role cannot edit or delete: a separate role runs the retention job. The one exception is a person's own request to be pseudonymised under KVKK, which swaps their name and address in the log, keeps the rows and is itself recorded. Tested on the in-process database; the roles are set up on the server before any customer data goes in. | Expected by buyers In enterprise suites | In the app |
| Incoming transmittals and review codesRegisters incoming transmittals and the review codes returned with them. | Common In enterprise suites | In the app |
| Sync with the employer's document system ★Reads the files exported from the employer's document system (Aconex, Procore, ProjectWise, AVEVA, SharePoint, ACC and others; Excel or CSV): the register, the transmittal history and the review results, with column matching and a table of the system's status words. A file import, not a live connection: no vendor API is called and nothing is written back. Twelve systems; the column names come from vendor documentation and are checked against a real export on the first project. | Rare | In the app |
| Review codes and numbering masks per project ★Supports project-specific review code sets (Aramco, EXPRO A to E in Arabic and English, 1-4, CFIHOS) chosen in the project settings, and numbering masks. | Rare In enterprise suites | In the app |
| Bulk upload from ExcelLoads document registers from Excel with local-language headings, using a web screen and a sample file. | Common In enterprise suites | In the app |
| Inter-discipline check (IDC) and comment resolution sheet (CRS)Carries comments from one review round to the next and produces the comment resolution sheet. | Rare In enterprise suites | In the app |
| Supplier document list generated from the order ★Builds the supplier document list of each order, with due dates, review class and final or interim lines, typed by hand, loaded from an Excel sheet and checked line by line, or taken from the documents the class of each tag on the order requires. Before the order is accepted the supplier's proposed exceptions are listed and accepted or refused with a reason, each audited; the order is not accepted while one is open. | Rare In enterprise suites | In the app |
| Placeholders for planned documents ★Tracks planned, reserved, received, accepted and cancelled placeholders in the register, extra lines added after issue and their effect on progress and on the document index. | Rare In enterprise suites | In the app |
| Upload checks with blocking and warning rules ★Checks each submission's file type, number, revision sequence, title and required fields against blocking and warning rules before it enters the register. Rules that read inside the file run too: the virus scan, searchable text, the native file beside the PDF, the number and revision written in the title block against the typed ones, and the stamp block; a VDRL line chooses which of them it asks for.Not yet: Not built: PDF/A conformance, the issue purpose sequence, the revision table check, package completeness, the tag cross-reference list and the same-file hash check. The title block is read from the text layer only: a scanned sheet is not read, and the sheet's own drawing border is not recognised. | Rare In enterprise suites | In the app |
| Rejection screen for suppliers with fix suggestions ★Shows which rule failed, in plain Turkish or English, what was found, what was expected and how to fix it. Suppliers enter their own document rows in the portal, checked by the same rules, and the list of rejections exports to CSV. | Not found elsewhere | In the app |
| Pre-check without login ★Lets a supplier test a file against the rules before sending it, without signing in: the PDF and its native file are read in memory and thrown away, and the page says which rule did not run (no scanner on the server, no text to read).Not yet: A scanned sheet with no text layer has its title block unread (no text recognition in this check), and a file over 25 MB is checked by its name and size only. | Not found elsewhere | In the app |
| Tag-linked supplier document list ★Expects the documents a tag's class requires (such as spare parts lists and operating manuals per CFIHOS) automatically at order time: when a tag is put on a purchase order, each document its class requires becomes a line of the order's VDRL with its due date, and what is missing shows on the tag and on the order. A project edits the documents each class requires; at handover rule H13 checks that each is on the order's VDRL and final, and an order line may name several tags.Not yet: The full CFIHOS document type library is not loaded: the starter classes carry ten document types and the project edits them. A tag on no order is not judged by H13. | Not found elsewhere | In the app |
| Numbering rules and checksDefines document numbering rules and checks numbers against them. | Common In enterprise suites | In the app |
| Oil and gas numbering template (PRJ-ORG-UNT-DIS-TYP-SEQ-SHT-L) ★A ready numbering procedure for oil, gas and industrial facilities, loaded into a project in one step by the project administrator: the number NNNN-A-NNN-AA-AAA-NNNNN-NN-A, the origin codes, 37 discipline codes and 64 document types in two languages, and an example unit register the project must approve; a code the project already holds is never reassigned. Document control reserves the next running number of a PRJ-ORG-UNT-DIS-TYP prefix, one register for every organisation that shares an origin code; reserved, cancelled, void and superseded numbers are never reused and a reserved number has no revision. A wrong number is corrected before the first issue (the old one stays as void); after issue a replacement needs the project administrator's approval and a supersession link. The revision is two digits and a release indicator (01R, 03C, 06X), the number never resets when the indicator changes and comments or a rejection do not change the issued revision. The purpose of each issue (IFR, IFA, IFI, ENQ, PUR, AFD, AFC, AFU, ASB) is recorded apart from the owner's return code, and an approval purpose is applied only after an authorised release. Files are named by number and revision, checked on upload and in the vendor intake check (final and final2 are refused, approved rendition suffixes are allowed). The security class is metadata of the document, never part of the number. When an issued number is replaced, the recipients of the earlier transmittals get a notice in both languages (mailed when the recipient is an address), the old document's cover names the new number and revision, and the first page of a file is checked for the number and revision.Not yet: Not built (2026-10-28): access by security class, and the class in the register list; tying the purpose of an outgoing transmittal to the issue purpose codes. | Rare | In the app |
| Full-text search inside filesSearches what is written inside the uploaded files, page by page. The text of every file is read in the background after it is stored: the text layer of PDFs, Word and Excel files through the same PDF the review shows (so a page number is the page the viewer shows), plain text files, and Inbox mails with their attachments. Pages with no text layer and photos are read by OCR on the server (Tesseract, Turkish and English, with a cap of pages for one file and for one day in the project settings) and are marked as OCR in the results. The search uses PostgreSQL full text with Turkish and English stemming, picked by the language of each page, plus trigrams, so a Turkish word typed without the Turkish letters is found, part of a number is enough (101 finds P-101A), an exact phrase can be quoted and a word can be left out. Results are ranked, filtered by discipline, stage, type and date, show the page and the text around the words, and open the document on that page; only files the person may see are searched, and the quick search (Ctrl+K) has a line that opens it. A project administrator can read the files stored before this existed. The words of drawings are kept with their place on the sheet (the text layer and the OCR of scanned pages), so a search frames the word or tag it found on the drawing, with Next and Previous to walk through the places. No OCR of handwriting yet, and the OCR accuracy on scanned engineering sheets is not measured. Reading restricted documents (2026-11-02, slice 136c): the code exists, is switched off and is not sold, and is on in no project. Once the rule is turned on, the files, review, cover, search hits and Linto answers of a document in the class Restricted are closed to everyone without an active grant, each read under a grant is written to the audit trail, and the project administrator gets a read-only impact preview. Slice 136d (2026-11-03): a restricted document is also never sent outside with any grant (outgoing transmittal, workflow send, agent step, RFQ, owner and vendor review rounds are refused), is named in mail and digests by number only, leaves out its title and files on an RFQ link, the site phone pack, a pre-check answer, the maintenance system and an alarm work order, and is never read by the AI service; Slice 136e (2026-11-03): the project export (data, full export, server script), the Excel lists and the as-built package leave out a restricted document's title, file names, comments and files and the manifest lists the documents by number; files with the same bytes in other stores (mail attachment, archive, payment attachment, close-out, photo, contract, HSE, feedback) do not open without a live grant; deleting a project is refused after an export that left documents out; an outside person's submission check shows the title only with a live grant and the anonymous pre-check link never does; Slice 136f (2026-11-03): the title vault, proven on sample data only: a restricted document's title moves to a table the application's role cannot read, the number and the word Restricted show everywhere, the old copies change in the same transaction, only a person with a live grant reads the title, and the way-back command restores every title and copy exactly; no real data was moved and moving it needs the product owner's approval. It is not turned on without the product owner's separate decision. | Common In enterprise suites | In the app |
| ISO 19650 statuses, IFC upload, BEP and EIR templatesSupports ISO 19650 document statuses, a common data environment view by state, IFC upload with indexing (storeys, elements with GUIDs and tag text, matched to the tag register), and BIM execution plan and employer requirement templates written as documents of the register.Not yet: An optional project setting (off by default) gives the ISO 19650 states and suitability codes S0 to S7, A1, B1 and CR, the revision forms P01.01, P01 and C01, the seven-field container naming as a number mask with field by field checks, moves between states only through check, review and approve and authorise and accept (two workflow templates), a CDE view grouped by state that exports to Excel, and archiving a published container with a reason. An IFC file uploaded to a document is read in a worker thread by a reader of our own (no web-ifc, no CDN) for its storeys and elements; the tag text (the Tag field, a property named Tag, Reference, Mark or KKS, then the name) is matched to the tag register. The BEP and EIR open as register documents with template sections that follow the headings of ISO 19650-2. Model checks: the project writes its own rules (none is shipped) and runs them on a model that has been read: a property is present, its value is in a list or a range, an element's classification reference is a class of the tag profile, its tag text is a tag of the register, every tag of a system has an element; each result names the element, the rule and the model's revision, the failures come as Excel, and nothing is written to the model or the register. Not built: IFC geometry and a model viewer, schema validation, clash checks, a library of ready rules, properties that come from a type object or are quantities, the information delivery plan and the standard's own text. The names of some codes differ between sources, the field lengths are read from two examples and a container keeps its revision label when it changes state. | Common In enterprise suites | Partly in the app |
Progress · 31
| P6 import and exportReads Primavera P6 schedules from XER files, Turkish code pages and decimal commas included, with their logic and float. Gives progress back as an XER fragment or an Excel list of the fields Lintara owns. The export has been checked only against our own reader: one round trip through a real P6 is still needed before a customer relies on it. | Expected by buyers In enterprise suites | In the app |
| P6 schedule health check (DCMA 14) and schedule performance by time ★Works out the 14 DCMA schedule checks from an imported XER by code (not AI), each as pass or fail with the activities that fail it and limits the project can change; missed tasks, BEI and time-based SPI(t) use a baseline file imported next to it. The critical path test is a structural check, not the DCMA delay test. | Rare | In the app |
| Link to P6 activity ID and broken-link detection ★A document carries the P6 activity ID it belongs to (typed, read from a register column or chosen from the schedule) and is linked by it. Every schedule import finds the activities that were removed, renamed or moved to another WBS node and lists the broken links with their documents. The owner's register dump (one row for each change of stage of a document, read from Excel or CSV) is replayed against the imported schedule: for each activity the progress the owner's record supports on a day, worked out from the project's stage credits and weights, is set beside what P6 says, and the activities P6 calls complete that the owner has not approved are marked. Nothing is written to P6 or to the register. No real owner's dump has been seen yet: the column names and status words are our guess and a word table corrects them. | Rare In enterprise suites | In the app |
| Link P6 activities to documents ★Finds each document's number in a P6 user field (an MS Project text field), activity code, activity ID or activity name, reports which rule linked what and how many activities and documents stay unlinked, and shows the progress the documents earn next to P6's physical percent complete. Optionally fills a document's planned date from the linked activity's finish (off by default). Nothing is sent to P6 from the app; progress goes back only as a file the planner takes in. | Rare In enterprise suites | In the app |
| Change managementKeeps a register of change requests with origin, reason, estimated cost and time, and links to RFIs, letters and documents, from identified through priced and submitted to the owner's decision. An approved value posts to the budget's cost codes in the same step, with an audit entry; a decision is final. | Expected by buyers In enterprise suites | In the app |
| Progress and credit from deliverables ★Turns document and deliverable status into progress and earned credit. | Rare In enterprise suites | In the app |
| Versioned contract credit rules ★Applies one rule engine, versioned per contract, to documents and site items: weighted steps earned by controlled records (a document stage, a signed diary line, an inspection passed, a handover check), a version that freezes at the first credit, and a recalculation report shown item by item before a change is adopted. Credit is never typed: it is taken back only with a reason, and the history shows which record earned each step. Progress, the S-curve and the payment application read the same engine, by system, discipline, area and package. The two starter templates are labelled examples, not a standard.Not yet: Not built: a trend-only flag on a quantity, a screen for the planned dates of steps, loading a site item list from Excel. The starter weights have not been checked against a real contract. | Not found elsewhere | In the app |
| Site credit library for concrete, steel, pipe, cable, equipment ★Provides 13 step templates for concrete, structural steel, piping (line and spool), cable, equipment and instrument loops, where each step is earned by a record such as an NDE result, megger report, test package or inspection passed. Every template names its source (Southern Company's rules of credit, BHEL tender annexes, a lecture) and how it was read; the two with no published source, the piping spool and the instrument loop, are labelled our own estimate, not a standard, and none is offered as the standard. A template is copied into a draft of the rules of credit and adjusted to the contract; the copy remembers its template, its source and what was changed, and the audit trail names the template added.Not yet: Not built: weights imported from a contract schedule, owner tables beyond Southern and BHEL. The weights have not been checked against a real contract. | Rare In enterprise suites | In the app |
| Document status gates site credit ★Links a site item to the drawings its work is built from and to its as-built drawing. It warns when credit was earned from a drawing that was not yet issued for construction (naming the step, the day and the drawing's stage that day), flags a revision after credit with links to both revisions, and earns the as-built step only when the as-built drawing is approved, taking it back if the drawing goes back. The sign panel of a diary report lists the lines that are about to earn credit from a drawing not yet issued. A warning never blocks a record: the site did the work, and the register and the work disagree.Not yet: Not built: a warning on the phone when a line is entered offline (the sign panel of a diary report warns on the web), linking drawings automatically from a tag's documents, acknowledging a revision flag without new credit. | Not found elsewhere | In the app |
| Write actuals back to P6Prepares the physical percent complete and the actual start and finish worked out from the documents for the activities they are linked to, as three user fields (the default, touching nothing P6 owns) or directly as physical percent. A preview lists what changes against the last import; logic, durations and the dates P6 holds are never rewritten. The planner takes the XER or Excel file into P6; it has been checked only against our own reader. | Rare In enterprise suites | In the app |
| Procurement progress, credit on delivery ★Splits a purchase order into lines and credits each line only from records: the order issued, the stage of the vendor documents in the order's VDRL, an inspection of its tag (manufacturing, factory acceptance test, shipment) and the delivery note entered on site, on the web and on a phone. Delivery is measured: a partial delivery earns credit in proportion to the quantity received and undamaged, damaged goods earn nothing until they are replaced, more than ordered is recorded with a warning, and a wrong delivery note is voided with a reason and stays on record. A delivery sets the tag's site status to delivered. The rules of credit carry an order line rule with a labelled example (the weights are our own estimate, not a standard). The Progress page shows the procurement curve beside engineering and construction without adding them; order lines stay out of the main progress figure, the S-curve and the payment application.Not yet: Not built: delivery notes kept on a phone without signal, procurement credit in earned value and the payment application, loading order lines from Excel or the ERP, crediting the shipped step from the shipment record (the shipment record now exists on the Logistics and materials page, but shipped is still earned by an inspection). The example weights have not been checked against a real contract. | Rare In enterprise suites | In the app |
| Material approval requests (MAR)Asks the owner or the consultant to approve a material before it is bought. A MAR is a register document, so it takes its number from the project's number format, takes files and has revisions; it carries the material, the specification clause, the manufacturer and the supplier proposed, the area, discipline and system (codes of the project dictionary when it keeps them), the day the approval is needed and the submittal documents and samples. It goes to the owner as an owner review round of its document with the project's own return codes (approved, approved with comments, revise and resubmit, rejected); where it stands is read from the round and what the code means, never typed, and the code is written on the revision it answered while a new revision keeps the same MAR number and keeps what that revision proposed. When the answer came by e-mail or on a transmittal, document control records it in one step. An order line can name the material it buys: with no approved MAR (approved or approved with comments) the line is warned about, and when the project administrator sets the rule to block, an order cannot be issued and a line cannot be added to an issued order; a draft order is never held up, and goods of a material with no approved MAR are still received and flagged on the delivery note. The status board counts the MARs by state and lists the reviews that are late with the owner, the MARs not approved by the day they were needed, and the materials ordered and delivered without an approval; it downloads as Excel. A MAR that is late with the owner shows in My tasks of the person who wrote it and in the daily notices to that person and to document control.Not yet: Not built (2026-10-26): a register of procedure qualification records (PQR), which are written as documents by their number in the list of a MAR; matching an order line to a MAR by supplier or manufacturer (the match is by the name of the material); a reminder before the review day (only a late review is mailed); the owner reviewing a MAR from a template with its own return code (a template round ends approved or returned and is read that way); reading the material from a bill of quantities. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Construction work packages, readiness constraints, lookahead and recovery planGroups the site items of one crew in one area into a work package. The package code is the code in the package field of the items and order lines, so the drawings (the construction drawings linked to the items), the materials (order lines and their deliveries), the budget hours and the inspections come from the records, and the linked schedule activities give the package its days and whether it has started. What holds a package is worked out from the records and never ticked by hand: a drawing not issued for construction or not linked, an order line not delivered in full, an RFI not closed (linked, or naming one of its drawings), a permit not issued or run out, and a package before it that is not complete; a constraint no record shows is written by hand with its owner and day. The statuses are not ready, ready, in progress, complete and cancelled. The lookahead places the packages that start in the next three or six weeks in the week they start, shows how ready each is and what holds it, and prints for the weekly meeting; a constraint becomes a line of the action log with an owner, and finishing the action does not clear the constraint. The recovery tab lists the packages that fall behind the plan of their items by the margin the project administrator sets (10 points to begin with) with the constraints that hold them, and keeps the plan the team writes with its date and the packages that were behind that day. Site readiness items not done in the package's area, and subcontractor fronts tied to the package, hold it too (2026-10-28; see their own rows).Not yet: Not built (2026-10-26): an NCR register to feed the NCR constraint (the constraint kind exists in the core and is fed once the register does), the codes of a project dictionary (the area and the crew are typed), an Excel file of the lookahead (it prints only) and tasks assigned inside a recovery plan. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Earned value (EVM), S-curve, estimate at completionEarned against planned S-curve of weighted document and site item credit, and earned value in money on the Cost page: BAC from the current budget by cost code, PV and EV from the credit of the items mapped to each code weighted by its budget, AC from the ERP lines up to the posting date; CV, SV, CPI, SPI, SPI(t), three named EAC formulas (BAC / CPI, AC + (BAC - EV), AC + (BAC - EV) / (CPI x SPI)), ETC, VAC and TCPI. The mapping is a table written by package, area, system, discipline or single item number; the strongest rule wins, and the share of the weight that is not mapped and the codes left outside the measure are shown, never dropped. With no actual cost, a partial one or one older than 45 days, CPI and the forecasts say "not enough actual cost" instead of a number. A PV, EV and AC curve, a breakdown by cost code and by package and an Excel file; issuing a payment application freezes the figures at its cut-off and shows each period's change.Not yet: PV from a cost-loaded P6 schedule (it comes from the planned dates in the register), a past date reads today's budget, actual cost is not spread over packages (the accounts book to cost codes), no hand-entered ETC per code, and it is not tried on a real project's ERP file yet. | Common In enterprise suites | In the app |
| Interface management ★Keeps a register of interfaces between packages, disciplines and companies, each with the data items to agree and a due date, from identified through data requested and agreed to closed. Linked documents, RFIs and letters are checked against the register; an interface closes only when every data item is agreed, its documents are final and no decision about it is open. Overdue interfaces are marked, the document drawer lists the interfaces a document serves, and every step leaves an audit entry. A Map tab draws the parties and the interfaces between them, coloured by their worst state; interfaces link to tags (a number of the register or a former one), a tag's panel lists its interfaces, and the map downloads in the demo's Interface Map file format (not yet loaded into the separate Interface Map tool). | Rare | In the app |
| Decision and action logRecords decisions with date, who decided, what was decided, the reason and what changed, linked to the interfaces, documents, RFIs and letters they touch. A question stays open until a person records the decision with its reason; a decided record is never edited, and a later decision supersedes it. Actions have an owner, a due date and the record they came from (a meeting, a decision, an interface, an RFI or none); they stay open until the owner says done, a cancellation and a reopening need a reason, nothing is deleted, and an overdue action shows on the owner's task list and in the daily e-mail. The minutes of a meeting hold the notes, the attendees and the actions that came out, do not change once issued, and download as a PDF in Turkish or English.Not yet: Not built: actions raised from a letter, a risk or a claim, a reminder before the due date, recurring actions, minutes as Excel or Word, a link from a decision to the meeting it was taken in. | Common In enterprise suites | In the app |
| Risk register and portfolio viewKeeps a risk register and a portfolio view across projects. Each risk has an owner, a cause, a likelihood and an impact on the project's own scale (the number of levels, their names and where the medium and high bands start are the project's setting; the starting scale is an example, not a standard), a score, a response, a status (open, occurred, closed) and a review day. A review records the levels as they stand, the response and the next day, and the earlier values stay in the audit trail. A risk links to the claims, changes and cost codes it concerns, the open ones sit on a heat map, the list downloads as Excel, and a risk past its review day comes up in the daily e-mail notices. No money or time is forecast from a risk. | Common In enterprise suites | In the app |
| Lessons learned and the company lessons libraryKeeps the lessons written at any time in the project: what happened, the effect, the cause, what to do next time, the process (from a starting list, or a WBS code or a process name typed), tags, who raised it and the day, and the numbers of the risk, claim, change, document, RFI or letter it came from, checked against the registers (an NCR is kept as typed, as there is no NCR register yet). A lesson goes through review (draft, in review, accepted, rejected): it needs something to do next time before it is accepted, a rejection and a reopening need a reason, only a draft is edited or deleted, and every step is in the audit trail. The lessons download as Excel with their states, linked records and the library mark. A lessons log kept in another system, for example the export of a project platform, is read in from an Excel or CSV file: the columns are recognised by their English and Turkish names, a preview comes first, and the lessons are saved as drafts when you confirm. An accepted lesson is carried to the company library with no person's name, no linked record and no project number in it (the same lesson once); a new project of the company reads the lessons it picks in as risks (cause, event and effect and the response asked for filled in, likelihood and impact starting in the middle of the scale) or as checklist items in its action log, all in one step or none.Not yet: Not built (2026-10-26): versions and editing of a lesson in the library (a copy does not change; it is taken out and carried again), reading a lesson into an inspection plan step, the codes of a project dictionary (the process is typed) and updating lessons from Excel. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Business case and feasibility, with the project charter made from itKeeps the business case of a project in versions: the title, summary, background and objectives, the horizon in years and the discount rate, up to eight options each with CAPEX (once), OPEX (a year) and benefit (a year) lines (a benefit that is not money is a line with no amount), the assumptions with their source and owner, the recommended option and why. A table works out the net a year, the payback and the NPV from what is written by plain arithmetic and forecasts nothing. Sending a version needs the summary, a cost estimate for every option, assumptions with sources, the recommended option and its reason; it then goes through a chain of approval steps, each with a name and optionally the e-mail of the person who decides (with none, an administrator or a controller decides). A step can be approved, returned with a reason (back to a draft) or rejected with a reason, who did it and when is kept, and when the last step approves the version is approved and the earlier approved version is superseded. An approved version never changes; the next version starts from it, and only one version is open at a time. From an approved version the charter is made as a register document numbered with the project code and -CHR-001 (weight zero, so it is outside the progress), with a PDF of the options, estimates, decision and assumptions in Turkish or English as its file; each later approved version makes a new revision of the same document. Every step is in the audit trail.Not yet: Not built (2026-10-28): a Word or Excel charter (PDF only), an internal rate of return and sensitivity analysis (only the discount rate and horizon), e-mail notices and e-signature for an approval step, the approval chain using the document workflow templates (it has a chain of its own), and a connection to an owner's or a lender's own system. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Requirements register with traceability to deliverables, documents and tests, and a coverage viewKeeps the requirements of a project numbered with the project code (PROJ-REQ-0001): title, statement, category (functional, performance, safety, regulatory, interface, operational), priority, source (a contract clause, specification or stakeholder), owner and acceptance criterion, through the states draft, agreed, verified and withdrawn. Each requirement links to deliverables (the work breakdown codes of the project dictionary that have no active code under them), documents (by any number they carry in the register) and tests (inspection numbers); a link to a record that is not there is refused. A requirement is agreed only with its statement, source, owner and acceptance criterion, and verified only when at least one inspection is linked and every linked inspection is signed (the unsigned ones are named); reopening and withdrawing need a reason, and only a draft is edited or deleted. The coverage view shows requirements with no deliverable, document or test, the deliverables no requirement asks for, and links to a deliverable that is no longer active; a withdrawn requirement is in no count. The register filters by state, priority, missing link and a search, and every step is in the audit trail.Not yet: Not built (2026-10-28): a test record other than inspections (no separate FAT, SAT or commissioning test records), importing requirements from a specification or from a tool such as DOORS or Jama, an Excel download, a version or baseline of the whole requirement set, and extracting requirements from the text of a document. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Phase gates (FEL 1-3, FID, mechanical completion) with criteria read from the records and recorded decisionsKeeps the gates a project passes in order. One button adds the usual five (FEL 1, FEL 2, FEL 3, the final investment decision, mechanical completion) with names in the language the person works in and starting criteria; the thresholds are starting values to set to the company's own procedure, and a project can write gates of its own. There are nine kinds of criterion: an approved business case, the share of requirements traced to a deliverable and verified, an approved and current design basis, the share of documents at a stage or later (filtered by type and discipline), open NCRs (filtered by severity), open punch items (by category), a budget in place, and a criterion ticked by a person. The ones the records can answer are worked out again every time the gate is read and nothing about them is stored, and each line says in both languages what was found and what is needed; a person ticks a manual criterion with a note, and the person and the day are kept. The decision (go, go with conditions, hold, stop, recycle) belongs to an administrator or a controller and is only ever added to the gate's record: "go" is recorded only when every criterion is met and no linked change is undecided, going ahead with a gap is "go with conditions" with the conditions written, and hold, stop and recycle need a reason. Each decision keeps what the criteria came to that day, and a gate with a decision keeps the criteria it was decided on. A change request of the change register is linked to the gate it affects, with its effect, and keeps the gate from a clean "go" until the owner has decided it; the API also says which gates a change affects. Every step is in the audit trail.Not yet: Not built (2026-10-28): a record that a budget was approved (the budget criterion looks at cost codes that have a budget), risk register, schedule (DCMA) and HSE criteria, reordering the gates, a decision that needs several people, reminder notices, a gate report as a printout, the linked gate showing on the change register page, and a connection to an owner's own stage-gate system. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Design basis (FEED): parameters, codes and standards and site data with source and revision, and what cites a valueKeeps the values a design is built on, numbered with the project code (PROJ-DBP-0001): design parameters, codes and standards, and site data, each with its value, unit, a required source, an optional source document of the register and notes, a revision starting at 0, and the states draft, approved and withdrawn. If the value, unit or source of an approved value changes, a reason is asked, the value becomes a new revision and goes back to a draft to be approved again, and the earlier revision goes to the history; the name, kind and notes can be corrected without a revision. A document or a calculation cites a value and records the revision it read (a document must be one of the register; a calculation that is not in the register is kept as typed). When a value changes, every document and calculation that cites the older revision is listed as waiting for a look, in the answer, the list, the panel of the value and the audit entry, and a person confirms each once it was checked against the new value. What a document rests on can be asked for, and the design basis criterion of a phase gate reads whether the values are approved and no citation is waiting. Withdrawing and reopening need a reason, and a draft that was never approved, revised or cited can be deleted.Not yet: Not built (2026-10-28): reading a citation from inside a document or calculation file (the citation is typed), a calculation engine or automatic updating of a document, Excel import and export, a position for site data, and a difference view between revisions. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Procurement packages with a strategy and a schedule worked back from the programmeKeeps what the project buys as packages numbered with the project code (PROJ-PKG-001): title, description, the strategy (single source with its required reason, competitive bids, frame agreement), the WBS codes (active codes of the project dictionary when it has any) and the tags (checked against the tag list), the cost code and an estimate. The procurement schedule is worked out on every look: the date the goods are needed on site is typed, or taken from the planned start of the programme activity the package names (P6 XER, MS Project) less a margin (14 days by default), and the steps are counted back from it: the order a lead time before it, the bids opened an evaluation period (14 days) before the order, the RFQ a bid period (21 days) before that, the requisition approved a requisition period (10 days) before the RFQ; each number can be typed over on the package. That a step is done is read from the records, never typed (the approved requisition, the RFQ issued, the bids opened, the award made); a step whose day has passed and is not done is late, one due within 14 days is soon, and the packages are listed by the date their orders are due. Where a package stands (planned, requisition, out to tender, evaluation, awarded) is read from the records that follow it. Cancelling takes a reason and is refused for a package with an order placed or an RFQ still open; every change is in the audit trail with the field before and after. Not there: a working-day calendar (the days are calendar days), updating the lead time from the bids that come, comparing the estimate with the budget. Not tried on a real project. | Rare | In the app |
| Material requisition with lines, tags, specifications, documents, revisions and an approval chainA requisition numbered with the project code (PROJ-MR-001) writes the lines to be bought, each with its description, quantity, unit, tag and the specification, or the number of the register document that holds it, and names the documents that state the need (data sheets, specifications, drawings, by any number the register knows) with the date needed and where to deliver. Tags and documents are checked against the tag list and the register as it is saved. It is kept in revisions: a draft revision goes through a chain of named approval steps (by default the discipline lead and the procurement manager; the person whose e-mail address a step carries decides it, a step with none is decided by an administrator or a controller; returning and rejecting need a reason), an approved revision never changes, and a change is a new revision that starts from the approved one, one open revision at a time. When a revision is sent, what it changed against the one before (lines and documents added, removed or changed) is written down, and approving it puts the earlier approved revision aside. To send, the title, the date needed, at least one line and each line's description, quantity, unit and specification must be there; the same tag on two lines is warned about. Cancelling takes a reason and closes every revision, and is refused while an RFQ made from it is still going. Not there: the approval chain using the document workflow templates (it has its own), e-mail notice and e-signature for a step, filling a requisition from store stock, linking it to a material approval request by itself, importing requisitions from Excel. Not tried on a real project. | Rare | In the app |
| RFQ and bids: supplier link, sealed bids, technical and commercial evaluation, recommendation and award that makes the order and its VDRLAn RFQ numbered with the project code (PROJ-RFQ-001) takes its lines and documents from an approved requisition revision, with a closing day, an opening day after it, the validity asked, and the project's currency as the one every bid is tabulated in. It is not issued until the bidders on the list reach what the package strategy asks (1 for a single source, 3 for competitive bids, 2 for a frame agreement). Issuing makes each bidder a link that needs no account (only a hash is kept, it is shown once, a lost one is made again and the old one stops, and requests are limited per address and per link): the bidder sees the lines and the files of the documents at the revision they were at when the RFQ was issued, asks up to 20 questions and sends the bid, as many times as they like until the closing day is over, the latest one counting and the earlier ones kept; they never see the project or another bidder. The team answers questions, can share an answer with everyone without the name of who asked, and writes notices to all bidders. The bids are sealed until the opening day: the team sees that a bid came and from whom, and no price, term or note is on any screen, API answer, audit entry or project export (the export's manifest says how many bids it holds back); opening is for administrators and controllers only and is refused before the opening day and when no bid came. After the opening the technical evaluation is done line by line (compliant, deviation, not compliant, with a note required for the last two; a line the bidder did not offer is not compliant by itself) and the commercial tabulation is worked out by code in one currency: each line to the cent in the bid's currency, a bid in another currency converted at a rate a person records with its source, the total being the sum of the converted lines; only bids that are technically compliant with every line priced are ranked, with how far each is over the lowest and the best price of each line. A recommendation needs a reason when it is not the lowest eligible bid or the only eligible one in a competitive tender, and keeps who, when and why. An administrator or a controller makes the award: the recommendation is checked again against the bids as they stand, then the draft purchase order (supplier, value, cost code), its lines at the bid's prices with the package number, the tie of the lines' tags to the order and the order's VDRL (the documents the RFQ listed, with those the tag classes ask for) are made in one transaction, so that if one cannot be made none is. A bid that came on paper or by e-mail is entered by hand after the opening with the day it arrived, which must be by the closing day. Cancelling takes a reason and closes the links. Not there: a bid's attachments (PDF) are not taken through the link, the invitation e-mail is not sent by the application (you send the link yourself), the seal is at application level and not encryption (someone with direct access to the database sees the prices), weighted scoring, bid bond tracking, a connection to EKAP or another tender platform, a call-off order under a frame agreement, an addendum to an RFQ after the closing day. Not tried on a real project. | Rare | In the app |
| Stakeholder register, power and interest grid, engagement plan and contact logKeeps the organisations and people outside the project team: the owner, authorities, utilities, neighbours, lenders, the local community, suppliers and advisers; a person is tied to the organisation they belong to. Interest and influence are typed from 1 to 5 (4 and 5 are high) and the power and interest grid sorts the stakeholders into four boxes: manage closely, keep satisfied, keep informed, monitor. The engagement plan holds what the team wants from the stakeholder, how, who on the team keeps the relationship, how many days between contacts, and the engagement now and the one wanted (unaware, resistant, neutral, supportive, leading) with the gap. The contact log takes a call, an e-mail, a visit or a note with its day; a letter or a meeting is linked by its number from the registers already in the app, and its day and subject are read from there and not retyped, and the letters and meetings that name the stakeholder are offered to link. The last and next contact days are shown and a stakeholder whose contact day has passed is marked and can be filtered. A stakeholder is archived with a reason, every change is in the audit trail, and the owner and other outside people do not see the register, as it holds what the team thinks of them.Not yet: Not built (2026-10-26): a daily e-mail reminder for a late contact, sending a letter to many stakeholders at once, and printing or an Excel file of the grid. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Supervision firm dashboardShows the supervising firm late approvals, open final accounts and reasons for time extensions.Not yet: A read-only page in the Controls section for the owner's side and the supervision firm that works for it (its people join free as owner-side participants, with a company of kind consultant). It shows the approvals past their date, the final account with its clocks and who it waits for, the claims for time waiting for an answer with the reason each gives (no money), the NCRs waiting for the owner's approval and the material approval requests in review. Not built (2026-10-26): narrowing the supervision firm to the steps that name its own company when the owner's and its people share a project, a reminder e-mail, an Excel file of the page. It has not been tried on a real project. | Not found elsewhere | In the app |
| MS Project XML importReads schedules saved from MS Project as XML in addition to P6 XER: tasks with WBS, dates, percent complete and custom text fields (UTF-8, UTF-16 and Windows-1254 files), and the logic: predecessor links with type and lag, task calendars, total and free slack, constraints, durations and the project's calendars, so the schedule health check, the critical path and the time impact view work on it as on an XER. They show on the same Schedule page and link to documents by the same rules. Nothing is written back to MS Project. | Not found elsewhere | In the app |
| Review delay report ★Reports reply times by reviewer and by employer against the contract review period.Not yet: The Review delays tab of the pilot measures reports each reviewer, each organisation (the owner, the supervision firm, your own company) and each discipline: rounds, median and 90th percentile answer time in working days, the share within the period, the days late, what is overdue now, the longest open reviews and a trend by month, by discipline and document type, with an Excel file. The project administrator can enter the contract's period for each document type (days, working or calendar, clause); a review round that starts takes that period, else the one in the project settings (the main contract register has no review period field), stores which one it used, and is not moved when the settings change later; the review page shows the source of its due date. Each time a document goes to the owner or the consultant is recorded with its transmittal number (an issued transmittal, a transmittal read from a history, an owner review, a register sheet's submitted day); the report measures an owner review from that day and the register and the document page show it. A claim for time opens an evidence page that sums the late answers between the event and the owner's answer, by organisation and one by one, to print or download as Excel. The project administrator can subscribe people to a weekly or monthly e-mail with the late returns, the longest open reviews and the change since the last report by organisation, with the Excel file attached and a one-click way to stop it; nothing is sent when nothing is late unless the person asked. Not built: the owner's home page and the supervision panel work out the due date of a document that has no review yet from the project setting, not from the type's period. It has not been tried on a real project. | Rare | In the app |
| Quantitative risk: Monte Carlo on cost and schedule, P50 and P80, tornado chartA model is a cost or schedule model: items with a three-point estimate (least, most likely, most) and risk events with a chance and a three-point impact that is added if the event happens; triangular or PERT, 1,000 to 50,000 runs and a confidence level that starts at P80. A run is seeded, so the same model with the same seed gives the same result and a test checks that it repeats. The result gives the base (the sum of the most likely values), the mean and spread, P10, P50, P80 and P90, the S-curve, the distribution, the chance that the base is enough, a tornado chart of the inputs that move the total most, and the proposed contingency (the value at the confidence level minus the base, also at P50 and P80). The result is stored with the SHA-256 of the model it was run from and is marked out of date once the model changes; each run goes to the audit trail with who ran it and the headline figures. A cost item can carry a cost code and an event can carry the number of a risk of the register (checked on write); "from the risk register" brings the open risks with a first chance read off their likelihood level. The result is a proposal: nothing is written to the budget, the estimate or the schedule by itself. Not yet: building the critical path from the schedule network (the chain is written by the user and the durations are added), correlation between inputs, and writing a result back to a risk of the register (on purpose); not tried on a real project. | Rare | In the app |
| Issue escalation with levels and time limits, and the effectiveness review of actionsThe project sets its levels: a name in both languages, who is told and after how many days late an item reaches the level; the starting list of four levels is an example the project administrator changes, and the days allowed for a minor, major and critical NCR and the days until an effectiveness review are set there too. The board brings the open actions, interfaces and NCRs; lateness is counted from the due day (for an NCR its raised day plus the days for its severity), the level an item should be at is worked out in code and compared with the level a person has recorded, and the items waiting to go up come first; an item with no due day cannot be late and is listed apart. A person records a step up with the level, the day, the person told and a required note: the record is added, never changed, the level cannot go below the one recorded, going above what the days late have reached is allowed and marked early, and every step goes to the audit trail. A finished action is reviewed after the set number of days (30 to start with): effective, partly or not effective, with what was looked at, and a follow-up is required unless it was fully effective; reviews due and late are counted and the latest review stands. The risk readers read it and the risk writers write it; outside parties do not see it. Not yet: sending the escalation by e-mail or in the daily notices (the page sends nothing), RFIs and decisions on the board, a public-holiday calendar (days are calendar days) and opening the follow-up action by itself; not tried on a real project. | Rare | In the app |
Cost and payments · 22
| Budget by cost breakdown structure (WBS)Holds the original budget by cost code (a WBS or cost breakdown number) and works out the current budget from the approved changes posted to it, with a cost overview of committed, invoiced, a simple forecast and variance. The codes also read as a tree (a code's parent is the part before its last separator, a parent that is not a code adds its children as a heading), and each code takes an estimate to complete you type: the estimate at completion is what the accounts booked (or was invoiced) plus it, with the simple forecast where none is typed. | Expected by buyers In enterprise suites | In the app |
| Commitments (purchase orders, subcontracts)Records purchase orders and subcontracts with value, cost code and supplier, through draft, issued, closed and cancelled. Invoices and credit notes are rows of their own, so invoiced to date is their sum; closing an order releases what was not invoiced. | Expected by buyers In enterprise suites | In the app |
| Contract registerHolds the main contract with the employer, its amendments as versions, the subcontracts let under it, and their terms and values.Not yet: The main contract is a register: parties, form, dates, original value, retention and advance terms, performance security and payment clocks, amendments as versions, subcontracts linked, the rules profile and payment rates read from it; each subcontract and order keeps its own terms (scope, price basis, retention, advance, payment period, dates, warranty, delay damages) as versions: the first terms and each amendment with its full terms, numbered, signed on a day, never below what is invoiced, moving the commitment's value in the same transaction; missing: a clause library (it needs contract texts and a lawyer's review). | Expected by buyers In enterprise suites | Partly in the app |
| Variations and change ordersTracks variations and change orders against contracts. A priced change is instructed as a variation with its value and time, approved or withdrawn when the owner's decision is recorded, added to the contract value and time with the pending ones shown apart, the cost budget and the payment items following, every step audited with who approved. An approved change of the owner can revise a commitment: the commitment's terms version names it and moves the value in the same transaction, and a change order to a subcontractor is recorded as a numbered version of the subcontract with its value and time. Extension of time claims are followed on the Claims page. | Expected by buyers In enterprise suites | In the app |
| Turkish progress payment set (hakedis) with deductions and advance recovery ★Produces the Turkish public-works progress payment set with deductions and advance payment recovery. KDV, KDV withholding with its ratio, kind of work and rule source, income tax withholding, stamp tax with its rate and base, SGK and other legal deductions as lines, and penalties with their reasons are worked out on the back cover from a versioned table (a change applies from the application you give; issued applications keep theirs). A contract in USD or EUR needs a rule saying which lines apply and how the lira rate is fixed; nothing is guessed. The advance is a ledger with its guarantee letter, the cap and a balance that never goes below zero. The cover, report, work-done list, summary, quantity list and price difference come as one Excel file and a printable PDF, with the owner's name and signature blocks set in the project. An application whose totals, deductions or advance balance do not hold is not issued. The official stamped form of an owner may differ. The remaining sheets are on the Payment set extras page, made from the stored applications as Excel and PDF: the summary by work group, the weight list, the materials-on-site record with its deduction, the yearly allowance tranches against the work programme, the unrecovered advance and the final guarantee followed with Pn, the work increase limit check, the time extension table and the final account. The document index (dizi pusulasi) lists the sheets of the set with their pages and the attachments of the file, which are checked before an application is issued.Not yet: Everything the sheets and the checks need is built and tested; missing: an owner's own stamped format and electronic signature (the official blank forms were not obtained, and a qualified electronic signature provider has not been chosen). | Rare | Partly in the app |
| Calculated progress payment sheets with versioned deductions ★Builds the calculated sheets of the Turkish progress payment set from any application: the cover, the report (the back cover with every deduction line and the amount payable), the work-done list, the payment summary (hakedis ozeti), the quantity list (metraj icmali, the green book) and the price difference table, as one Excel file with Turkish headings and a printable PDF drawn from the same data, with the owner's name and contract data on every sheet and signature blocks set per owner. Deduction rates are versioned tables: a change applies from an application on and issued applications keep theirs. The document index (dizi pusulasi) is a sheet of the set too, with the attachments of the file checked before an application is issued. The summary by work group, the weight table, the stored-materials record and the allowance tranches are sheets of the Payment set extras page, from the same document model. The official blank forms were not obtained, so these are working sheets with the same columns and the layout is editable per project.Not yet: Hakedis ozeti, Metraj icmali and Fiyat farki are built as Excel; missing: deductions held as versioned tables, abstract and covers, official forms. | Rare | Partly in the app |
| Progress payment application from the register ★Works out a numbered payment application from payment items: each has a contract value earned by the progress of a system's or discipline's documents at the cut-off date, by a milestone, or by a measured quantity. It shows previous, this period and to date per item, then gross, retention, advance recovery and net due. An issued application is frozen with the rates it used and a correction goes in the next one; it downloads as Excel. The price adjustment is a line of the application, with its inputs shown. VAT, tax withholding and penalties come later. | Rare | In the app |
| Automatic payment cover sheet checks ★Keeps the attachments of a payment file in a register: the SGK and tax no-debt letters, the guarantee letter, the insurance policy, the work programme and any kind the project adds, each with its number, issuer, issue and expiry dates, pages, copies and file; the project says which applications need which kind. An application is not issued while a needed attachment is missing or expires before the application's day (or a set number of days after it); each is listed with its reason in both languages, and it can be passed only with a written reason that is audited. The document index (dizi pusulasi) is a sheet of the set, in Excel and PDF: the other sheets with their pages and the attachments with number, dates, pages and copies, in the order the project sets. The payment owners get an e-mail 30 and 7 days before an attachment expires. The stamped official index of an owner may differ; the sheet is a working sheet and its layout is editable per project. | Not found elsewhere | In the app |
| Price adjustment from stored indices ★Calculates price adjustment from a formula with a fixed part, B and weighted coefficients, each tied to an index series. Series keep the month, the value and the publication date; values are entered or read from a CSV with a preview and a confirmed apply. The adjustment line of an application shows every input (base and current index per coefficient, Pn, the base and the amount) and is frozen when the application is issued. Under the Turkish rules B is 0.90 and the advance is left alone while Pn is below 1. Each series can name where it is fetched from (the Central Bank's EVDS series code, or the CSV address of a TUIK table on TUIK's own hosts): Fetch brings the missing months, a fetched value is only a proposal until a person approves it, and entering by hand or from a file works as before. Beside the contract's own formula, separate coefficient sets cover parts of the works (the price difference is the sum, a set an application used is fixed), and the low-month rule takes the lower of the programme month's and the application month's index for work done late against the programme. EVDS needs the company's API key on the server and has not been tried against a real account: the tests use a fake provider and a recorded answer; an application that spans two months has its index month chosen by hand. | Rare | In the app |
| Statutory payment periods for Turkish public works (KIK) ★Tracks the payment clock of each progress payment application: submitted, approved, accrued and paid dates recorded by hand, due dates from the project's periods (default approval 30, accrual 30, payment 15 days, editable, copied to the application when it is issued) and days late. The contract rules profile is chosen by the tender announcement date: before 2025-09-01 a period counts from the approval date itself, from 2025-09-01 from the day after. It only watches, and mails a reminder to the people who issue the payments 7, 3 and 1 days before a due day, on it, and every week while it is late (each person can switch it off). The contract's periods are shown beside the statutory ones of the standard contract (30, 30 and 15 days, 75 at most): a longer period is a warning for a tender announced before 2025-09-01 and a note after it. This is not legal advice. | Not found elsewhere | In the app |
| FIDIC payment statement and payment clocks ★Builds FIDIC Sub-Clause 14.3 statement lines, advance payment and retention fields, the 28-day interim and 56-day payment clocks, and the monthly progress report.Not yet: The application of a FIDIC contract reads as a Statement in the order of 14.3 on screen and in Excel, with the 28-day certificate and 56-day payment clocks, the retention limit and the advance repayment threshold applied as contract fields, and a label "check against your contract" on what the reports do not confirm; line (v) is the value of the materials on site from the materials record, the clocks send due-day reminders, and the monthly progress report (4.20, 4.21 in the 2017 books) is made from the records as Excel and PDF; missing: lines (vi) to (ix) worked out (other additions and deductions, provisional sums, release of retention, the Employer's utilities), changes in Laws (13.6), the 2017 Yellow and Silver texts, and what the Contract Data asks of the monthly report beyond the records (photographs, quality and safety records). | Rare In enterprise suites | Partly in the app |
| Gulf employer templates ★Provides the EXPRO payment certificate and reconciliation sheets, an invoice concurrence sheet, a ZATCA UBL 2.1 file with a QR code, and an invoice consistency check for Saudi government projects.Not yet: Built: from an issued application the EXPRO payment certificate (the layout of template EPM-KD0-TP-000046) and a reconciliation sheet, Arabic and English or either alone, as Excel and PDF, with the layout, columns, retention line, acceptance wording and signature blocks edited per project; an owner template slot (EXPRO, or another owner with the same layout edited from the project's sample, which says that no official form was found); the owner's certificate number and date; a VAT invoice entered or read from Excel, CSV or ZATCA UBL XML and checked against the certificate (amount before tax, VAT rate as a project setting, VAT, total, certificate number and date, with each mismatch explained in English, Turkish and Arabic), which cannot be marked sent while it fails unless a reason is given and audited; Lintara's own invoice concurrence sheet (contract, certificate and invoice data, the payment due date, a sign-off grid for the project's own list of functions, eight to start with, and the certificate's items for the cost code distribution that Project Controls fills in); and a ZATCA file from a VAT invoice: UBL 2.1 XML, the invoice counter, the hash of the file before it, the QR code (seller, VAT number, time, total, VAT), a signature through a signing provider and clearance or reporting through a service (interfaces with test providers; an unsigned file is not sent); an invoice can be entered in lines (at one of the project's two VAT rates, zero-rated or exempt, each of the last two with a reason code), a credit note is written against a sent invoice and checked against it, and an invoice can be in another currency with the VAT also stated in riyals at a rate and source a person enters; the ZATCA file carries them (a tax subtotal per category and rate, type 381 for a credit note, the riyal VAT first). Missing: Aramco, ADNOC and KOC forms were not found; EXPRO's stamped concurrence form is not reproduced; real ZATCA clearance needs the taxpayer's onboarding certificate and a ZATCA environment, the file's hash is the hash of our own stored XML and not ZATCA's canonical hash and cryptographic stamp, and the QR code has no Phase 2 fields; the Arabic has not been read by a native speaker; the VAT base is a project setting because the sources disagree; the list of reason codes has not been compared with ZATCA's current list; the exchange rate is entered by a person, not fetched or checked; a credit note cannot be read from a file; the credit note type and the riyal VAT fields have not been tried against a real ZATCA environment. | Rare | Partly in the app |
| FIDIC price adjustment formula (13.7, 13.8) ★Calculates price adjustment under the FIDIC formula: a fixed part and weighted coefficients against stored index series, as line (ii) of the payment application, with retention taken on the work and the adjustment together (14.3 iii). Red, Yellow and Silver are profiles of the contract. The date offsets for the indices (28 days before tender, the 49th day before period end) and the 13.6 adjustment for changes in legislation come later. | Not found elsewhere | In the app |
| E-invoice and electronic signature ★Makes the UBL-TR 1.2 e-Fatura or e-Arşiv XML of an issued payment (period amount, KDV, KDV withholding with its code, income tax note, from the figures stored with the application), checks it against our reading of the GİB rules, signs it through an e-signature provider (XAdES) that records who signed what and when, sends it through an integrator and writes the answer back to the payment; with no integrator connected the XML is downloaded and the answer recorded by hand. The integrator and signing interfaces are built with test providers only: a real integrator and a qualified electronic signature (NES, the customer's certificate and card) are the customer's own choice, GİB's official schema and schematron files are not in the system so passing the rules is not a certificate, and credit, exempt and export invoices are not built. | Rare | In the app |
| Claims and time extensions; ERP linkTracks claims and time extensions and links to the customer's ERP. A claim for time, money or both is kept from the event to the owner's answer: the clause relied on and the contract form (as typed), the day of notice, the particulars sent and the letters, RFIs, design submittals, site diary reports and documents that prove it, on one timeline. The notice and particulars clocks count from the day of the event by the days of the contract form; only the FIDIC forms start with 28 and 84 days (a law firm's commentary read in research report 31), the other forms start with none and the project administrator types the days and the clause its contract gives, and every page says to check the periods against the contract (not legal advice). The owner's answer is recorded as agreed, partly agreed or rejected; agreed days are added to the contract's completion date with their history, agreed money is a line of its own in the contract value apart from the variations, and a wrong answer is reopened with a reason. The extension warning of the design approval clock opens a claim draft. The ERP link is file imports (WBS, orders, actual lines) and a live read-only S/4HANA OData connection with a code mapping table and a match of orders, goods receipts and invoices (on the Cost page).Not yet: Claims and extensions of time are built. Delay analysis (a tab of the Schedule page): as planned against as built from the baseline, a windows analysis between kept updates (finish slip and the slip of the earlier update's critical path, read from the file's own total float), and a time impact view where a fragnet you write is inserted into an update and a simple engine reports the change of the finish day; a run writes nothing to the schedule or a claim, a saved analysis reaches a claim only when a person attaches it, and it is an analysis, not a legal opinion. Delay events and responsibility (2026-10-31): a person records events on a saved analysis (the activities, a window in calendar days with both ends counted, the cause in words, the claim's own kinds of evidence: letter, RFI, design submittal, site diary, document) and picks who is responsible (employer, contractor, neutral, not yet decided); the code never decides it, a change keeps the earlier value with who, when and why and overwrites no row; on the critical path the analysis found (the earlier update's critical path in a windows analysis, the path that sets the finish in a time impact view; an as-built analysis finds none) the days are counted as employer only, contractor only, neutral, concurrent (an employer and a contractor event overlap) and undecided (never an employer day), with the days off the critical path and with no event apart, and the concurrent windows are listed; how concurrent days are treated (time without money, apportionment, or another rule) is the contract's and the parties' question, so the page says so, applies no rule and gives no legal opinion, and the project manager may write the contract's rule as text only. The analysis linked to a claim shows on the claim's page with the names and digests of its input files, its slip, its events and the day counts; "days the analysis supports" (employer plus neutral days) is the analysis's own figure and is never written into the claim's days asked or agreed; the claims Excel file has one more sheet in both languages; every event, change, removal and rule is on the audit trail. MS Project logic (2026-11-02): the predecessor links (with type and lag), task calendars, total and free slack, constraints, durations and the project's calendars of an MS Project file are read where an XER import keeps them, so the 14 DCMA points, the critical path and the time impact work on it too, and the same network as XER and as MS Project gives the same answer; elapsed and percent lags are converted and reported as approximations. The activity ID of an event is checked against the imported schedule (an ID the schedule lacks, or a summary task, is flagged and the event still saves), and when the schedule holds the activity's calendar the working days of the window in that calendar, holidays included, show beside the calendar days, which stay the default. Missing: a rule for concurrent days that the code applies (it needs a decision the partners take from the contract), working days from an XER (its calendars are not read yet), the time impact engine using the file's calendars, slack and lag units checked against a real MS Project file, the effect of an extension on the programme, and a reminder by e-mail before a notice is due. | Rare In enterprise suites | Partly in the app |
| Final account tracker (public works) ★Records provisional acceptance, the final account handed in by the contractor and the supervision, the owner's approval, final acceptance and the final payment application in order, each with its day and reference. Three clocks count the periods: 6 months from provisional acceptance for the contractor and the supervision, 6 months for the owner's approval and 30 days after the last approval for the final payment application (the starting values of research report 35; the project administrator types the ones its contract gives, with the clause, and every page says to check them against the contract, not legal advice). The final payment application cannot be made before final acceptance, there is one, and none follows it. Where the contract has the rule, the share held on completed work with no final account is shown from provisional acceptance until the account is handed in; the page deducts nothing. | Not found elsewhere | In the app |
| Time extension record ★Each agreed claim and approved variation that gives days is an extension of time, and each keeps its reason (site handover, design approval, funds, permits, weather, increase of work, other), the days the delaying event began and ended, how the days were counted and the owner's decision reference; the days given are compared with the days of the event. After an approval a clock runs for the revised work programme (7 days to start with, article 17 of the General Specification as research report 35 reads it; a project setting, check against your contract): it shows on the project overview, is mailed once when it is waiting and once more when its day has passed, and stops when the day the programme was submitted is recorded. | Not found elsewhere | In the app |
| Progress payment attachments: quality records and insurance trackerGathers the quality attachments of a payment application from the app's own records for the period: the rebar delivery records, concrete laboratory results and site laboratory test records from signed inspections (the project says which checklist counts as which kind) and the photograph album from the site diary (printed as a PDF with a reduced copy of each picture, two or four to a page as the project sets, with the diary's date and work, the caption and the SHA-256 of the stored original; the place and camera fields are removed from the printed copy, the stored original never changes, a photograph that cannot be printed is listed as not printed with its reason, and an Excel list carries the file names and digests), each listed on the document index; a needed kind with no record stops the issue until a person writes a reason. Tracks insurance policies with their cover start and sum insured: a cover that starts after the site start stops the issue, a sum below the amount paid to date gives a warning, a day with no cover between the policies of one kind gives a warning (the kinds, such as contractor's all risk, third party and employer's liability, are the project's own list), a kind the contract requires with no policy in force on the cut-off date stops the issue until a person writes a reason, policies from before kinds stay "not stated" and stop nothing, and the usual 30 and 7 day expiry e-mail applies. Adds the seven attachments in the form Ilbank asks for (cover, inner page, price difference tracker, balancing table, ihzarat control table, insurance tracker, work tracker) as an option of the payment set, in Excel and PDF from the same data; the ihzarat table is filled from the materials-on-site record.Not yet: The stamped Ilbank forms were not obtained: the seven attachments are working sheets with the columns of what each is for, and the project edits their layout. | Not found elsewhere | Partly in the app |
| Paper-first outputs for Turkish public worksPrints the payment set and the green book on A4 and A3 ready for wet signature, with the measurement sheet (ataşman: lines of count and dimensions added up and compared with the quantity of the period), an e-signature option on the PDFs (PAdES, recording who signed what and when), a zip of PDF and metadata for BELGENET and other registry systems, and the contract milestones as CSV or JSON. The e-signature is built with a test provider only: a qualified signature needs the customer's certificate and card. The metadata and milestone field names are ours, because the owners' own field lists (BELGENET, EKAP, KaYa) were not found. | Not found elsewhere | In the app |
| SAP S/4HANA data importReads CSV or Excel files from SAP and other ERPs: the WBS list, purchase orders and subcontracts, and actual cost lines, laid out like the ME2N, CJI3 and KSB1 reports. Columns are found by their names or chosen once and kept for the project; a preview lists the cost codes the project does not have and the rows it could not read, and the file is applied only when confirmed. The same file twice adds nothing. The cost page shows actual cost beside committed and budget, with the source and date of the last import. Nothing is written back to SAP. A live read-only connection to an S/4HANA OData service gives the same records through the same rules, with an ERP code to project code mapping table, goods receipts and supplier invoices kept as records of their own and matched against the commitments, and the ERP invoices recorded on the commitments. The connection has been tried against a fake S/4HANA server only: the service paths and field names are our reading of the released APIs, a real SAP system needs the customer's address, credential and sample data, and putting the actual costs into the forecast is not built. | Common In enterprise suites | In the app |
| Cost estimates by class, with versions and conversion to the budgetAn estimate is a version with a class (AACE 18R-97, 5 to 1), a basis of estimate (scope, assumptions, exclusions, allowances, sources, the day it was priced and how far the project is defined), lines on the cost codes and a contingency percentage; amounts are rounded to the cent and added by cost code. The page shows the typical accuracy range of the class beside the total (the middle of the AACE ranges for the process industries, a guide and not a promise) and warns, without refusing, when the project definition does not fit the class, when no exclusions are written, or when a class 4 or 5 estimate carries less than 10 percent contingency. A draft is edited and deleted; issuing needs the scope, the assumptions, the pricing day and a line. An issued version never changes: a new version is made from it as a draft (one draft at a time), the old one becomes superseded when the new one is issued, and the difference between two versions is shown cost code by cost code. An issued version is converted to the budget in one step: the plan is shown first, a cost code that is not on record is created with the name a line gave it, the contingency goes to the code you pick or stays out of the budget (with a note), a code that has commitments is never changed, the step asks for a recent confirmation of your sign-in, and the earlier and new value of every code goes to the audit trail. The cost roles read it and the budget roles write it; the owner and outside parties do not see it. Not yet: row import from Excel or CSV, factored estimating helpers, several currencies and the link to measured quantities; the class ranges are for process industries, not building works; not tried on a real project. | Rare | In the app |
| Cash-flow forecast from the schedule, the commitments and the payment termsA month-by-month forecast of the money going out to suppliers and subcontractors and coming in from the owner, worked out in code each time it is read. The committed value of each issued order is spread over the first and last planned dates of the schedule, or over a window set on the order, by a straight, S, front-loaded or back-loaded curve, and moved by the days to pay; the part already invoiced falls due on the invoice day plus the terms, and an invoice past its due day with no payment recorded is counted in this month and listed. The income is the contract value spread over its own window and moved by the approval, accrual and payment days of the contract. The page puts the planned out, the paid and the forecast out, and the planned and forecast in, side by side, shows the difference between paid and planned for the months up to now and the deepest point of the running net as the funding the project needs; an order with no window is left out and named in a warning. Payments made and received are added with a day, an amount and a reference (a correction is a payment of the opposite sign); a payment tied to an order settles its oldest invoice. The window, curve and terms of each order, and the income window, are set by the cost roles and logged in the audit trail. Not yet: retention hold-back and advance recovery on the income, VAT and tax payments, several currencies, importing a bank or ERP payment file (payments are typed) and an income forecast from the payment applications; not tried on a real project. | Rare | In the app |
Site · 48
| Daily site report ★Records measured weather, labour, equipment, work done and quantities, delays tied to a notice or letter, instructions and visitors, with draft, submitted, signed and locked states. A signed report changes only by a dated addendum, signing starts the contractual objection period (10 days by default, set per project), and it exports as CSV and prints. Photos are uploaded from the phone or the report page and kept exactly as the camera made them, with the time they were taken, the GPS position and the device read from the file once and kept beside it (what the phone only claims is marked as a claim). The diary, photos and a credit entry, a work line that names a site item and its step, are written with no signal and applied once when the connection returns; a signed report is never added to. Weather from a station and photos printed as pictures come next. | Expected by buyers In enterprise suites | In the app |
| Inspection formsKeeps inspection and test plans: checklist steps with acceptance criteria and a review, witness or hold point for each party. An inspection is run from a plan against a system, an area or a tag, a person types each result, a hold point must be signed before the inspection is signed, and a failed step can start a punch item or a non-conformance report. A signed inspection is a record, and editing a plan leaves inspections already raised alone. Photos are uploaded to an inspection until it is signed, with the time, position and device each carries. An inspection that is done with every step passed and no hold point open earns the steps of the rule of credit tied to its tag, and the panel and the phone say beforehand which steps and at what weight. On the phone an inspection is raised from a test plan, even a new plan written there, results and photos are entered with no signal and everything is sent in order. Signing for the owner and a third party in the app comes next. | Expected by buyers In enterprise suites | In the app |
| Punch list with photo and locationKeeps the punch list by system or location with a category (A blocks handover, B does not, C cosmetic), the responsible company and a due date. The contractor marks an item done and the side that raised it verifies it; an A item that is not verified keeps blocking its system, and each system shows its open A items. An item that is more than a punch point can be raised as a non-conformance report. Photos are uploaded to an item until it is closed, kept as the camera made them with the time, GPS position and device, and the item's position comes from the phone or from the most accurate photo. What each category stops is set per contract: only A stops handover, A and B before commissioning, or B stops handover and may be rolled over into the warranty period by an agreement whose day and reference are recorded, or a scheme of the project's own. The Excel file carries the position, the roll-over and the photo count. | Expected by buyers In enterprise suites | In the app |
| Offline capture and sync ★Installs on a phone and works without a signal: the day's diary entry, an inspection result, a punch item and a non-conformance report are kept on the phone and sent once when the connection returns, however often the phone retries. Where the server copy is signed or locked it stays as it is and the person sees what was not applied and why. Photos (kept with the phone until the server has them), credit entries, a new inspection raised from a test plan and a new test plan are queued the same way and sent in the order they were written, so a result and a photo can name an inspection that is still only an entry in the queue. The airplane-mode acceptance test (a restart, a closed session, nothing lost, nothing made twice) runs as an automated test against the phone's queue rules and the server; a run on a real phone and syncing while the app is closed come next. | Expected by buyers In enterprise suites | In the app |
| Mobile drawings and markup; issue pins on drawingsOpens drawings on mobile, lets users mark them up and pin issues to the drawing. The PDF viewer with pins and markups works on a tablet with a finger or pen inside a review round. In the site app the current approved revision of the drawings linked to what a person works on (systems, areas, tags and the subjects of the planned inspections) is kept on the phone, up to a size the project sets, and opens with no signal at phone and tablet width with pinch zoom. Each drawing shows a stamp of its number, revision and status, and a copy the register has moved past turns red once the phone is online. A pin dropped on a page keeps the page and its place in PDF points and starts a punch item, a note on an inspection step or a question that opens an RFI with no addressee and no due date; it works offline and syncs like any site entry, and the record's page shows the drawing at the pin. On site a rectangle, a cloud or a highlight is drawn with a finger from the drawing's toolbar, with an optional note, kept like the office markup (a page and a box in PDF points, with the file and revision it was drawn on) and shown on the same page in the office review viewer; it works offline too. A free-text tool on site comes next. | Expected by buyers In enterprise suites | In the app |
| Site status by equipment item ★Shows site status for each equipment item: not started, delivered, installed, tested, ready for handover. The status is read from the project's records and never typed: a delivery note linked to the tag, a signed daily report with a line that names the tag and says it was installed, an inspection of the tag that passed with no hold point open, and the handover checks. The tag page and the plant view show the status with the record that set it; a record that skips a step is shown as a gap. A status can be set by hand only with a reason, and it is shown as set by hand beside what the records say. | Rare In enterprise suites | In the app |
| Free access for subcontractors ★Lets subcontractors and vendors use the system at no charge, and work in it. Choose their party on Members and they see only what is theirs: the documents their company originates (subcontractor) or the lines of the orders issued to their company (vendor), never another company's items and never cost. They send documents and new revisions with their files; each file goes through the same intake check as document control's, a blocking finding comes back with what was found and what would pass and nothing is stored, and a passing submission waits for document control to accept it or send it back with a reason they read on their own page. They answer the review comments on what they sent and see their due dates. Everything they do is audited with their party and company and shows to document control marked as coming from outside. A subcontractor can also open new documents, but only within the scope assigned to its company, document by document: document control assigns numbers with a title, type, discipline and system (typed or pasted as a list, all or nothing), and the subcontractor opens each document from its line, once, with the register's own checks. Closed to them: the rest of the register, cost, RFIs and letters, and any number nobody assigned. An e-mail when a line is assigned comes next. | Rare In enterprise suites | In the app |
| QR scanning; inspection test plan (ITP) and non-conformance report (NCR)Prints a QR code for each tag and site item that opens the site app on that record when scanned with the phone camera, and keeps non-conformance reports beside the inspection test plans (see inspection forms). A report records what does not conform, the requirement it breaks, where, the company responsible and the severity, and starts from a failed inspection step, a punch item, a site entry on the phone (offline too), a vendor inspection or by hand. A disposition is proposed (use as is, repair, rework, reject), the approvals the project asks for are recorded, corrective and preventive actions get an owner and a due date and come up in My tasks and the daily notices, an inspection that passed verifies the work, and every step is audited. When a project setting is on, an open report holds back the credit step it names until it closes; the handover report lists each system's open reports; trends by cause, discipline, subcontractor and month download as Excel. The app also has its own scanner: the Scan tab reads a code with the live camera, a photo file or typed text without the picture leaving the phone, and the owner's own QR codes (plates and cabinets already carrying a code of the owner's asset system) are mapped to tags and site items by a table loaded from the owner's file and by patterns, and read with no signal. Photos of a report are uploaded as files. The owner cannot give its own approval in the app, and the scanner has been tested against generated codes, not yet with a real phone camera. | Rare In enterprise suites | In the app |
| Welding procedures and welder qualifications (WPS, PQR, WPQ)A PQR is the record of a test weld: the standard (ISO 15614, ASME IX or other) as a field, the test day, the laboratory and report, the tests (visual, NDT, tensile, bend, impact, hardness, macro) and the ranges the test qualifies (process by its ISO 4063 number, base material group, thickness, smallest diameter, position, filler, preheat, interpass temperature and PWHT), typed by the person who reads the standard; it is approved when its tests are recorded and none failed, rejected with a reason otherwise, and an approved PQR is a record. A WPS carries the same variables revision by revision, a new revision starts as a draft from the last one, and a revision goes to review only on approved PQRs that cover its ranges (processes, groups and positions put together, thickness ranges joined where they meet, the smallest diameter); the reviewer approves it or returns it with a reason (a person of the owner or of an inspection body is recorded under the name typed), the approval day makes it the procedure in force and replaces the revision before it, and the register number of the WPS document links the review round of that document beside the revision. A welder is registered by stamp number and holds qualifications (ISO 9606-1, ASME IX or other) for one process each, with the ranges of the certificate, the test day, the certificate's own expiry and the continuity rule: it lapses when the welder has not welded with the process, or had it confirmed by the employer, for the months the project sets (6 by default, 1 to 24), and a lapsed qualification does not come back with a weld made after it; a welder with no qualification that stands is marked. A weld records its WPS revision and its welder with the process, group, thickness, diameter, position, filler, preheat, interpass temperature and PWHT day, and is checked on its own day against the revision as it stood then and the welder's qualification as it stood then; the project's setting records a weld that fails the check marked (the default) or refuses it, and the form shows the result as it is typed. The site item and the tag are checked against their registers, the NDT result is never typed but read from the inspection the weld links (a step or the whole), a failed weld raises one NCR that carries the WPS revision, the welder and the failed NDT, and a repair is a weld of its own that names the failed one. The Reports tab gives each welder's repair rate by count and by inch-diameter, the qualifications ending within 30 days and the lapsed ones, and the Excel file; the people who keep the records get a daily e-mail 30 and 7 days before a qualification ends. The page is for the contractor's own team and is closed to outside members; every step is in the audit trail.Not yet: Not built (2026-10-26): working the ranges out from the thickness and diameter tables of the standard (the ranges are typed), comparing the preheat and the PWHT of a WPS with its PQR, a prequalified procedure such as AWS D1.1, tying the approval of a revision to the review round of its document (the round is only shown), a rule that the author cannot approve their own revision, files and photographs, a link to the isometric or the drawing, a repair rate by weld length, and an NDT sampling percentage. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Site receipt: shortage, damage and surplus records (OS&D)A receiving report is written for each delivery on site: the supplier's delivery note number, the day, who took the goods in and, for the lines of the order that the note lists, the quantity the note states, the quantity received, accepted, short, damaged and over. The scan of the note and photographs are added from the phone's camera (the page works at phone width), and the QR code of an order line, printed from the page, opens the form with that line ticked. The report enters the delivery note of the order and only the accepted quantity earns credit, never the whole of what arrived: accepted is what is left after the damaged goods, up to the smaller of the note and what the order still needs; short and damaged quantities stay open on the line until replaced, credited back or written off. Each short, damaged or over quantity opens a numbered discrepancy record (OS&D) with a cause, the supplier's replies and an outcome: replacement delivery, repair, credit note, accepted as is with the owner's agreement written, return, or written off with a reason. Repaired and accepted-as-is quantities are accepted and earn credit from that day; credited and written-off quantities leave the order and the line is complete without them; a replacement closes the record when the report that brought it is named (and the record opens again if that report is voided). When the damage is a quality issue an NCR is raised in one click with the supplier as the responsible party. A vendor's people, as external participants, see and answer on their home page only the records of their own orders, with the photographs, and reach nothing else of the receiving. An order is the vendor's only when a VDRL issued to the vendor's organisation carries its number and that number fits exactly one order: the company name, a draft VDRL and the person's own order list give no access (the list only narrows), and two orders with the same number give access to neither; it is worked out on every request. New projects start on this rule; on a project that existed before, the project administrator previews what each vendor organisation would lose and what restores it (with a reason, a fresh second factor and an audit entry), announces a start day at least two working days away, each affected organisation's people are told in both languages, and the rule does not apply before that day; going back to the earlier rule is not offered. A VDRL is issued only to an organisation that has an active vendor person on the project. Damaged goods, and goods whose material has no approved MAR, are received on hold and cannot be issued to a work package until a named person releases them with a reason (a hold can be handed to one person at receipt: only that person or a project administrator releases it); an issue to a work package is cancelled with a reason. The register filters by supplier, order, state, kind, least age in days and a word, has an ageing view by supplier and age band, and downloads as Excel (register, ageing, receiving reports, goods on hold). The page is for the contractor's own team; every step is in the audit trail.Not yet: Not built (2026-10-27): a receiving report kept on a phone without signal, goods on hold feeding the materials constraint of a work package, a discrepancy opened from an older delivery note entered without a report, closing a record in parts with several outcomes (the shipping record, the put away in a store and the late shipments box are on the Logistics and materials page). Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Shipment planning and packing list with the dispatch release after the inspection releaseA shipment numbered with the project code (PROJ-SH-001) plans the part of an issued order that leaves the supplier: title, Incoterm, origin, destination, the day it is ready, the planned dispatch, the day it is needed on site and a customs mark. A line's quantity cannot be more than the order still has to ship after the quantity on the other shipments that stand (counted in SQL); a cancelled shipment gives its quantity back. The packing list is written as a whole: each package (crate, pallet, box, drum, bundle, skid, container, loose) with its marks, gross and net weight (net cannot be above gross), length, width and height (the volume is worked out) and what is inside (line, quantity, tag). A tag is one piece and sits in one package only, a line for a tag cannot carry another tag, a content that names none takes the tag of its line, and the packed quantity cannot pass the shipment's. The dispatch release is read, never typed: the packing list must be complete (every line fully packed, every package with a gross weight and dimensions) and, for every tag inside, the pre-shipment release inspection (the test plan the project names, or else one whose title says release for shipment or pre-shipment) must be signed, passed and have no hold point open; a missing, unsigned or failed inspection is counted by tag. Ahead of an inspection only an administrator or a controller can release, with a reason of at least 10 characters that stays on the shipment together with what the inspections said that day; nobody can release with an incomplete packing list, and the list of a released shipment does not change. Dispatching cannot be before the release day, writes the "picked up" step of the journey in the same transaction and cannot be undone by cancelling; a planned shipment is cancelled with a reason. Every change is in the audit trail with the person and the fields before and after. The page is for the contractor's own team; the owner's, subcontractors' and vendors' people do not reach it.Not yet: Not built (2026-10-28): the supplier entering the packing list through a link of their own (the contractor writes it), a PDF or Excel print of the packing list, QR labels for the packages, a notice of the shipment by e-mail, and approving the release through the document workflow templates. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Freight and customs: forwarder, mode, ETD and ETA, declarations, permits, milestone tracking and late shipments on tags and work packagesEach shipment has one booking with a forwarder: mode (sea, air, road, rail or courier), the booking reference, the B/L, AWB or CMR number, the carrier, the ports, the ETD, the ETA and the day planned at the site, with the customs and inland days that default to 3 and 2. The journey is six steps: booked (written with the first save), picked up (the dispatch of the shipment), departed, arrived, cleared customs (only for a shipment that crosses a border) and delivered to site; a step cannot be written before the ones before it or on an earlier day, not in the future, and the last one is taken back with a reason. Being late is never stored, it is read on every look: the planned day of each step comes from the booking, a step past its day and not done is late by the days since, one within a week is soon, and the forecast at the site is the planned day pushed by the longest delay, an estimate and not a promise. A shipment is late when a step is late or when the forecast is after the day needed (typed on the shipment, else the earliest planned start of the work packages its lines are bought for); it then shows in a Late shipments box on the page of every tag inside it or on its order lines and on the panel of the work package its order lines name, with the forecast and the day needed. Customs declarations (import, export, transit; number, office, broker, HS codes, duty and VAT with the currency) move from draft to filed, to queried or held when asked, and to cleared; a draft cannot go straight to cleared, a cleared one does not change, only a draft is deleted, and the customs step is written only when a declaration is cleared. Permits (import and export licence, dangerous goods permit, certificate of origin, phytosanitary and inspection certificate) carry a reference, the authority and their validity, and one that is not issued, has run out or will run out before the arrival shows as a warning. A forwarder's tracking file (Excel or CSV with shipment, event and date, English or Turkish headers) is read into steps and checked like an entry by hand; a row it cannot place, whose shipment it does not find or that breaks the order of the steps is counted apart with the reason and written nowhere. Every change is in the audit trail.Not yet: F1: the real connection to a tracking service and to customs' electronic system. Tracking has an interface (TrackingProvider), a fake provider in the tests and the Ask the tracking service button that calls it, and with none connected the button says so; a real connection needs an account with a container or flight tracking service, its credential kept sealed, and that service's event codes mapped to our steps. Customs declarations are typed by hand today: there is no connection to a customs broker's or the customs electronic system (BİLGE) and no sample declaration file was obtained. Posting the freight cost to the cost record, insurance and demurrage are not built. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | Partly in the app |
| Warehouse and inventory: stores and locations, put away from site receipt, stock by tag or bulk item, preservation tasks, issue to work packages, returns and surplusStores with a code and a kind (covered, open yard, container, cold room, hazardous) hold locations such as A-01-02; a store or a location that holds stock is not retired. Stock is never typed, it is the sum of a ledger of movements counted in SQL by item and location: put away, issue to a work package, return, transfer, count adjustment and surplus out. A movement is never changed or deleted (a wrong one is put right by another), a location cannot go below zero, and the item row is locked while a movement is checked so two people cannot take the same piece. A line of a site receiving report is put away up to what it accepted less what is already put away; stock no report holds (owner supplied, an opening balance) is put away with its reason; a report with goods put away is not voided. A tag item is one piece in one place at a time (found by its tag number in any case), a bulk item is counted in its unit; stock filters by tag, code or description, store and kind. Issue to a work package asks for the project's work package code; for goods bought on an order line it opens the material issue record (MI) of site receipt in the same transaction, so goods not accepted or on hold (no approved MAR, or damaged) do not leave, and a return writes the opposite entry there so the quantity can be issued again; an issue made from a store is not cancelled at site receipt. A return cannot be more than was issued to that package and not returned. A transfer is two legs under one number. A count writes the difference as an adjustment that needs its reason, a count that agrees leaves only an audit entry, and a tag is there or not. Surplus leaves with where it went (kept for reuse, returned to the supplier, sold, scrapped, handed to the owner) and to whom or which sale, and a summary adds it up. A preservation task (turn the shaft, change the desiccant) has an interval of 1 to 730 days and a first day; it is due an interval after it was last done, overdue after its day and soon within a week, a finding needs its words, and once the goods leave the stores it is not due. Every movement has a number (PROJ-SM-0001), a day and the person in the movement list and the audit trail.Not yet: Not built (2026-10-28): counting stock beyond what a work package needs as surplus by itself, e-mail reminders of preservation tasks, counting by phone or barcode, a minimum stock level and re-ordering, a PDF or Excel print of a store ticket, and a connection to a warehouse management system or the warehouse modules of SAP and Oracle. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Site readiness (mobilisation): a checklist per area of temporary facilities, utilities, authority permits and access, with owners and days, holding the work packages it coversA checklist item (PROJ-RDY-0001) is something that has to be in place before a crew can work in an area: the kind (temporary facilities, utilities, authority permits, access), the area (empty is the whole site; it is matched to the area of the work packages without regard to case or Turkish letters), what has to be in place, an owner (a person or a company), the day it is due, optionally only some work packages, a note, and for a permit the issuing authority. A standard checklist of 14 items (office, fencing and gates, storage, welfare; power, water, drainage, communications; building permit, road occupation or traffic permit, utility connection permit; access road, entrance gate, crane pad) is written for an area in Turkish or English in one step; a title the area already has in either language is not added twice, and if the owner or the day is missing nothing is written. The state is read from the records: open, overdue, done, not needed, permit ran out. A day done cannot be in the future; an authority permit needs the number the authority gave, with a last valid day that is optional and cannot be before the day issued; "not needed" and "open again" need a reason of at least 5 characters; an open item is changed, a done or not needed item is opened again first; nothing is deleted and every step is in the audit trail with the old and new values. The per-area table shows done, open, overdue, the share done and whether the area is ready (at least one needed item and none holding). Feeding the work packages: an item that is not done, or a permit that has run out or will run out before the work starts, holds the work packages it covers (the packages of its area, or the package codes written on it; an item with no area holds every package), shows on the work package page as a "Site readiness" constraint with its owner and day, and goes by itself when the item is done; nothing about a hold is stored, it is read on every look. The page never says that work on site is safe and is not a permit to work (permits to work are the HSE module, which this slice does not touch). The contractor's own people read it (the viewer seat reads), the administrator, controller and planner write it; the owner's, subcontractors' and vendors' people have no access.Not yet: Not built (2026-10-28): tying an item to a P6 activity, an action opened from an item, e-mail reminders for late items, importing and exporting the items as Excel, a standard checklist of the project's own (the list is fixed in the code), and a file or photo attached to an item. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Subcontractor execution: work fronts of the subcontractors, what holds them, and field coordination meetings with their actionsThe Subcontractor fronts page has three tabs. Fronts: a front (PROJ-FRT-0001) is the place and scope given to a subcontractor picked from the subcontractor register of the Contract page: title, area, scope, planned start and finish and, optionally, the work package it is tied to (its code must exist). States: planned, open to work, paused, complete, cancelled. A front is handed over by the site team: with a constraint still open it needs a reason of at least 10 characters, which stays on the front; pausing, cancelling and reopening need a reason; completing leaves no open constraint and cannot be before the day it was handed over; a front still planned past its planned start, or not complete past its planned finish, shows as late; the subcontractor changes only while the front is planned and no front is deleted. If the owner has not approved the subcontractor or the subcontract does not show as signed, the front's page warns and does not block (the register's own rule). Constraints: the kind (access, drawings, materials, utilities, permit, work before it, equipment, manpower, other), what stops the work, who clears it, the day it is to be cleared by (not in the past) and who reported it, numbered PROJ-FRT-0001-C1; clearing needs a day and a note saying what cleared it and the constraint is not deleted; the Constraints tab lists every open constraint of every front, the most overdue first. An action of the action log is made from a constraint (its title carries the constraint's number, its owner and day are written); finishing the action does not clear the constraint. Feeding the work packages: a tied front holds its package while it is not handed over, is paused or has an open constraint, and the work package page shows each as a "Work front" constraint; a complete or cancelled front holds nothing. Field coordination meetings: a meeting is the minutes of the action log (subject, day, place, chair, attendees, notes; not edited once issued; PDF in Turkish or English) and also keeps who it was with (one subcontractor or all) and the open constraints that were on the table. The agenda is made from the open constraints of the chosen subcontractor, the most overdue first, and is kept on the meeting as it was that day (if a constraint is cleared afterwards the minutes still show what was talked about); empty notes start with the agenda; the minutes and the actions that came out are written in one step, each action carries the meeting's number as its source and can be tied to a constraint of the agenda; the actions still open from earlier meetings with the same subcontractor are shown to be asked about; an action can be added after the minutes are issued. The contractor's own people read it, the administrator, controller and planner write it; the owner's, subcontractors' and vendors' people have no access; every step is in the audit trail.Not yet: Not built (2026-10-28): the subcontractor writing a constraint or seeing their own front from an account of their own (the site team writes them), e-mail reminders for constraints and meetings, an Excel or Word print of the minutes, tying a front to a schedule activity, adding a line to an agenda by hand, and a recurring weekly meeting. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Quality audit programme with findings tied to NCRs and actions, and the completeness of the records of each systemAn audit has a title, a kind (internal, supplier, subcontractor or outside body), a scope, the criteria (standard and clauses), an auditor, the audited and a planned day; it is edited while planned, recorded as held (the day cannot be ahead of today), closed when no finding is open, cancelled with a reason and reopened with a reason. Findings are written only on a held audit: a major or minor nonconformity (with the day it is put right), an observation or an opportunity for improvement, numbered from the audit's number. A finding is tied to an NCR and to actions by their numbers, checked against the records; when it is closed the NCR and the actions are read again, so a finding does not close while one of them is open, a nonconformity cannot close with no link, and a closing note is required; a closed finding is reopened with a reason. The programme counts the audits planned, past their day, held and closed, the open major and minor nonconformities and the late findings. The records tab works out, for each system of the tag register, the inspections, the punch list and the NCRs, the share of inspections signed, the open punch items and NCRs and a state (complete, open items, incomplete, no records) from the records each time; an inspection of a tag counts for the tag's system and an inspection of an area for no system, with the number left out shown. The risk readers read it and the quality roles write it; outside parties do not see it. Not yet: an audit checklist and a report output (PDF), a yearly programme template, the supplier answering a finding directly, and counting MARs, test packs and welding records as required records (only inspections, the punch list and NCRs count now); not tried on a real project. | Rare | In the app |
| HSE plan, hazard register and task risk assessments linked to work packagesThe HSE plan is a version with its number in the document register (checked if written) and a review interval; it is written as a draft, approved with a fresh second-factor code by someone other than its author who is named as the plan approver in an authority record (an administrator is not enough), takes the place of the plan before it and gets its review day, which shows in red once past. The hazard register holds the activity, the hazard, its consequence, likelihood and severity (1 to 5), the controls, the likelihood and severity after them, an owner and a review day; the score is the product, and a band (low, medium, high, extreme) comes only from the risk matrix the customer approved, recorded by the appointed HSE manager with its version, its document and who approved it; without one the hazard is shown as not rated and no band rule applies, and records made before 2026-10-28 keep their rating with the note "rated under the former default scale". The risk after the controls cannot be higher than before; with an approved matrix a hazard above low risk lists its controls and "controlled" needs a reason if the risk after them is still high; closing and reopening ask for a reason. A task risk assessment is linked to a work package of the project, with its steps (hazard, risk before and after) and the kinds of permit the work needs; someone other than its maker (the account that wrote it, or the name typed as the assessor) who is named as an assessment approver in an authority record approves it with a fresh second-factor code, it is not approved while a step is still extreme after its controls under an approved matrix, and it is withdrawn with a reason. Every change is one transaction with an audit entry. The risk readers read it, the quality roles write it, and outside parties do not see it. There is no default matrix: the scale is the customer's approved project data; the page gives no legal advice.Not yet: Not built (2026-10-28): a hazard library and ready task analyses, writing the sections of the plan in the app (the plan is the register document today), and linking an assessment to an ITP or a schedule activity. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Inductions and competencies, permit records (Record Only) and the administrative start record of a work packageA person has a name, company, trade and badge number (there is no identity number field). The site induction and nine kinds of competency are kept with an issue and expiry day, a certificate number and the issuer; the state (valid, expiring in 30 days, expired, none) is worked out each time, and a renewed certificate takes the place of the old one. Permits to work, isolation (LOTO) and SIMOPS are Disabled on every project, new and existing. Record Only is switched on only by two different named people, the site or PTW responsible and the appointed HSE manager, each with a reason and a fresh second-factor code; authority is an authority record (a named person, a role, from, to, granted by, reason) that a project administrator creates, and an administrator, an agent or the AI has none by being what it is; loading the customer's procedure changes nothing. In Record Only the app records a permit that a competent, authorised person issued in the site's own system or book: its source (free text, no default), its number there, who asked, who issued it and in which role as the outside permit shows them, the document reference, evidence files, the validity days and the other signatories. Lintara's own status is "Recorded"; the state the source reports (issued, suspended, closed, cancelled) is shown apart and only recorded. The software never issues a permit, starts work or closes a permit and does not say whether an area is safe: approving, issuing, suspending, resuming and closing a permit are reachable for no one. The person who asked for a permit is never its issuer or a signatory and one person holds one role on a permit, checked on the server. Gas readings are real measured values with unit, time, instrument, calibration and the person who measured, and the software gives no pass or fail. An isolation names a tag of the tag register, and a verification or restoration is recorded by the signed-in person, not a typed name, never by the person who recorded it or is named as applying it. No AI or agent path reaches a permit or any HSE record, and an agent step on an action that an incident, drill, permit or assessment waits on is refused. Permits recorded before 2026-10-28 under the former workflow stay readable exactly as they were. The work package start record is an administrative check of the HSE records, not a permit to work and not a safety approval: it lists each open work package with the permit kinds its approved assessments name and notes a missing assessment record or (in Record Only) a permit record that does not show as issued at its source and valid today; recording a start over a note needs a reason that is kept with the notes, and a start never becomes or creates a permit. Every step is one transaction with an audit entry.Not yet: Not built (2026-10-28): operational e-permit to work (the app as the permit system: it needs an independent competent HSE assessment, a software safety verification and the customer's or operator's site approval, and is a separate, later package), a printable permit form (the customer's own permit form was not obtained), the pilot customer's permit source (open: a paper book or a system), wiring the start record into the readiness of the Work packages page and the daily report, checking a certificate with the issuing body's register (needs access to an outside body), badge or QR gate entry, and the customer's configurable certificate and gate model (MC, RFC, RFSU, PAC: no default sequence is built). Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| HSE observations and inspections on site, incident investigation, and LTIFR and TRIR from hours workedAn observation (unsafe act, unsafe condition, good practice or stop work) has what was seen, the place, severity, the company that puts it right and a due day; it is closed with a note, reopened with a reason and counted late. An HSE inspection has an area, an inspector and an eight-line starting checklist (OK, Not OK, Not applicable; an inspection with every line Not applicable is shown as "not checked", never as clear); each line not OK opens, in the same transaction, an observation for the company due in a week. Both are written on the phone in the site app without signal, kept with a client id and applied once; the phone holds the file names of photographs and the pictures themselves are added on the page (photographs or PDFs, up to twenty per record). An incident has one of eight classes (near miss, first aid, medical treatment, restricted work, lost time injury, fatality, property damage, environmental), day and time, place, company, days lost and the worst credible likelihood and severity; no field takes the name of the person hurt (personal health data is outside this release; a value kept from before shows only to the people named as health data readers). An investigation is needed for a recordable case, property damage, an environmental incident or a high potential (rated only under a customer-approved risk matrix) (investigator, method, root cause classes, contributing factors, summary); a serious incident does not close without a completed investigation, a linked action, every linked action done and a closing note. Corrective actions are lines of the action log, raised from the incident or linked by number and read again on closing. The day, recipient and reference of a report to an authority are recorded; the app does not say whether one is due or by when. Hours worked are entered by month and company, by hand or proposed from the labour lines of signed daily reports (people times hours). The LTIFR (lost time injuries per million hours), the TRIR (recordable cases per 200,000 hours) and the rate of days lost are worked out in SQL by month, as a running total and over the last 12 months; a cancelled incident is left out, a month with no hours has no rate, and a test compares the SQL with the same formula in the core. Every step is one transaction with an audit entry.Not yet: Not built (2026-10-28): keeping the pictures themselves in the phone's offline queue (only file names today), a printable authority notification and incident report (the forms of the social security institution and of the employer were not obtained), importing hours from an access-control or turnstile system (the customer's system and its export format were not obtained; the proposal from daily reports and entry by hand work today), rates by company and trade, and the rate bases an employer may ask for. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Environmental controls, waste register by type and contractor, and emergency drillsA control has an aspect (air, water, noise, dust, spills, waste, energy, other), the control, a limit, how many days pass between checks and who checks. A check records the day, the result (in order or breach), a reading and a note, and a breach needs what was found; a breach stands until a later check finds it in order, a control past its check day shows late, one never checked shows that, and no check is entered on a control taken out of use. The waste register holds a consignment number (once), one of ten waste types, quantity and unit, the contractor who carried it, the destination and the day removed; hazardous and oily waste ask for the carrier's licence number and the manifest. The quantities are summed by type, contractor and unit (different units are not added), and a consignment entered wrongly is voided with a reason, keeps its row and leaves the totals. A drill (fire evacuation, spill response, medical emergency, rescue) has a place, a scenario and a planned day; it is recorded as held with the day (not ahead of today), the people who took part and the time it took, findings are written on a held drill and can raise an action in the action log linked to the finding, a finding does not close while its action is open, a drill does not close while a finding is open, and cancelling and reopening ask for a reason. A kind not held for six months with none planned is shown as due again. Every step is one transaction with an audit entry.Not yet: Not built (2026-10-28): linking noise and dust meters to a control (the plant data page has a reader, but no mapping of a meter to a control), checking a manifest in the national waste tracking system (needs access to an outside system and credentials; the manifest number is typed today), an environmental aspect and impact register, the drill interval as a project setting (fixed at 180 days) and a printable waste tracking form. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| The HSE plan pinned to a register revision, and who has read itA draft HSE plan is pinned to one revision of a document of the register: the document and the revision are checked against the register, and the name and SHA-256 of the file attached to that revision are kept. The pin of an approved plan does not change, and if the register moves on to a newer revision a note says so. Members of the project acknowledge the plan in force for themselves, and a person who can write records a worker on site from a signed sheet, with a note; one record per person, written with the pinned revision, a register plan cannot be acknowledged before it is pinned, and the people who have not are listed with the share who have. It records that the plan was read; it does not show that it was understood or that anyone is competent. Every step is one transaction with an audit entry. Story HSE-G1 (report 50, HS-07).Not yet: Not built (2026-10-28): tying the acknowledgement to the completions of a training path, a reminder e-mail to the people who have not read the plan, asking for the acknowledgement again by itself when a new version of the plan is approved, and a company-level HSE policy document. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Obligations register with applicability decisions and review days, no verdict of complianceAn obligation holds the jurisdiction, the authority, the law, regulation, standard or permit condition, its version, the days it is operative, the source address, its owner on the project, the day the source was last verified, the review interval in months and the evidence documents, and is numbered. The applicability decision (applies, applies in part, does not apply) is made by a person who an authority record names as the HSE governance approver and who did not record the obligation, with a rationale and a fresh second-factor code; being an administrator is not enough. The review day is worked out from the decision day and shows overdue once passed; if the name or version of the instrument changes the earlier decision no longer stands and a new one is awaited, and every earlier decision stays on record. An obligation is withdrawn with a reason, never deleted. There is no field or count that says "compliant". Every step is one transaction with an audit entry. Story HSE-G2 (report 50, HS-08).Not yet: Not built (2026-10-28): following the text of the legislation and its amendments by itself, a ready list of obligations by country (the country profile question is open), linking the results of compliance audits, and reminder e-mails. The register gives no legal advice. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| HSE checklist templates: released versions, their source and their use in an inspectionA template has a title, a source (the customer procedure and its revision, or the project's own list; it must be written) and lines, each of which can be required and carries a source section. It starts as a draft; a person who an authority record names as the HSE governance approver, and who did not write the list, releases it with a fresh second-factor code. A released version never changes: "New version" opens a new draft from a copy, and releasing it retires the version before. Loading a customer procedure, or writing a reference, does not release a list. In an HSE inspection a released list can be chosen: its lines come in order, a required line marked not applicable needs the reason, and the inspection keeps the number and version of the list; with none chosen the old starting list is used and the inspection is free-form. Every step is one transaction with an audit entry. Story HSE-G3 (report 50, HS-09).Not yet: Not built (2026-10-28): putting the templates in the offline queue of the site app (the phone uses the starting list today), recurring HSE inspections on the maintenance plan engine, and importing a customer's own checklist file. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Toolbox talks and HSE briefings: attendance, language and the signed sheetA record holds the kind (toolbox talk or briefing), the day (not in the future), the topic, the language (Turkish, English, Arabic, Russian, other), who gave it, optionally the number of the assessment it briefs (checked against the register) and the work package, notes, and the people who attended, chosen from the HSE people register; it is numbered. The signed sheet is attached to the record as a photograph or a PDF and kept with its SHA-256. Late arrivals are added to the list and nobody is taken off it; a wrong record is voided with a reason, stays on record and is not counted. The number of talks and of people who attended feed the objectives and the management review. Every step is one transaction with an audit entry. Story HSE-G4 (report 50, HS-10).Not yet: Not built (2026-10-28): recording a talk and taking signatures on the phone without signal (only from the page today), attendance from an access card or turnstile system, talk templates and a programme, and a count of talks per person per year. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Task risk assessment steps linked to the hazard register, exposed groups, and revisions that supersedeAn assessment step can be linked to a hazard of the hazard register (the number is checked against the register) and names the groups it exposes (at most ten); steps written before have neither and stay as they were. An approved assessment is copied into a new draft with "Revise" (one open revision for an assessment at a time); when the revision is approved it takes the place of the old one in the same transaction, and the old assessment stays on record as superseded with its row, steps and approval and is not counted on the work package start record. The author of a revision cannot approve it, and approval asks for the authority record and a fresh second-factor code (the rule of slice 120 is unchanged). Every step is one transaction with an audit entry. Story HSE-G5 (report 50, HS-11).Not yet: Not built (2026-10-28): flagging the linked steps when a hazard of the register changes, showing the difference between two revisions, and linking the exposed groups to the people register. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Verification of the controls on hazards: who checked, by what method, with what evidenceEach line of the "Controls" text of a hazard is a control, and a check is written for each control: the method (inspection, observation, test, document review, interview, other), the day (not in the future), the result (in place, in part, not in place; a finding is required for in part and not in place), the signed-in person who checked, and an optional file of evidence (a photograph or a PDF, kept with its SHA-256). A check is added and does not replace the earlier one; the list shows the newest and the history stays on record; the controls never checked and the number not (fully) in place are shown. The person who checks writes the result; the software does not decide that a control works. Every step is one transaction with an audit entry. Story HSE-G6 (report 50, HS-12).Not yet: Not built (2026-10-28): a check interval with a warning for an overdue check (the project would set it; there is no default), turning the controls out of the hazard text into records of their own, and recording a check on the phone. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Closure evidence and a verifier for actions linked to HSE records; raising an action from an observationThe actions linked to an incident, a drill finding or an observation are listed; once an action is marked done in the action log, its closure evidence (what was done and where it can be seen, with an optional photograph or PDF) is written and becomes "awaiting verification". The verifier is a person other than the one who wrote the evidence and the one who marked the action done; a rejection needs a reason, the owner writes new evidence and the earlier record stays. From an open observation "Raise an action" opens an action in the action log and links it to the observation in one transaction. An agent or an AI cannot touch these actions; the rules of the action log itself are unchanged, and the evidence and the verification are a record on the HSE side. Every step is one transaction with an audit entry. Story HSE-G7 (report 50, HS-13).Not yet: Not built (2026-10-28): evidence that is not yet verified stopping an incident from closing (an incident closes under today's rule; a separate decision), reminder e-mails for verification, and more than one action from one observation. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| HSE objectives and a management review with a data snapshotAn objective has a title, a metric (LTIFR, TRIR, near-miss reports, open and late observations, hazards with a late review, toolbox talks and drills held, the share who read the plan, the share of closed actions verified), a direction (at most or at least), a target number, a baseline, an owner and a review day; the project sets the target and there is no default. The standing is worked out from the project's own records: on target, off target or not measurable (the rate of a month with no hours entered, or a share with nobody to count, is not counted as zero). A management review holds the day, the chair, the attendees, the agenda, the decisions and the next day; when it is written the rates, the objectives, the plan and its pinned revision, the risk matrix and the action counts are frozen into the minutes (a snapshot), refreshed on request while it is a draft; once the decisions are written a person named as the HSE governance approver, other than the one who wrote the minutes, approves it with a fresh second-factor code, and an approved review and its snapshot do not change. Every step is one transaction with an audit entry. Story HSE-G8 (report 50, HS-14).Not yet: Not built (2026-10-28): joining the management review with the meeting minutes of the action log (it is a table of its own), splitting objectives into periods, a mapping to the clauses of ISO 45001, and charts. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| The customer-approved, versioned risk matrix: the matrix in force, its use, and rating againThe risk matrix is versioned project data that the customer approved (the source document and revision, who approved it for the customer, the day; the appointed HSE manager records it, slice 120); there is no default matrix and until one is approved no record is rated. The matrix page shows the matrix in force as a table of the scores by band, and counts which version the hazards, assessments and incidents were rated under. An open hazard or a draft assessment left unrated, or rated under the former scale, can be rated again by a person once a matrix is approved (the earlier scale stays in the audit trail); no record is rated again by itself, and an approved assessment is not rated again but revised. Every step is one transaction with an audit entry. Story HSE-G9 (report 50, HS-03, decision DEC-003).Not yet: Not built (2026-10-28): scales other than five by five (three by three, four by four, own axis names), a preview of the whole project under a new matrix version, and attaching the customer's signed approval as a document. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Time and place of HSE photographs; files added after closing are marked lateWhen a file is added to an HSE record the time and the latitude and longitude the device reported are kept together (one cannot be given without the other; a future time and an impossible position are refused). They stay a claim of the device and are not checked against the picture. A file added to an observation, an incident, an action closure, a signed sheet or a permit record after that record closed is marked "added after the record was closed", and the files before it do not change. Every step is one transaction with an audit entry. Story HSE-R1 (report 50, HS-15).Not yet: Not built (2026-10-28): the phone reading the EXIF of a photograph and filling in the position by itself (today the fields are typed or entered on the page) and a time stamp in the offline queue. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Restricted incident and observation details for a named reader list, read log, anonymous observationsThe details of an incident or an observation (the description, the person field, the investigation, the closing note) can be marked "restricted" with a reason: they are hidden in the lists and in the evidence pack and only people named as health data readers open them, every opening being logged with the reader, the record and the time; only a reader lifts a restriction (being an administrator is not enough). An observation can be entered anonymously: no name shows on screen or in the list (the signed audit entry still holds the account). No new health data field is added (DEC-006). Every step is one transaction with an audit entry. Story HSE-R2 (report 50, HS-16).Not yet: Not built (2026-10-28): masking the restricted fields in the project export (the HSE tables are not in the export yet), hiding the account name in the audit entry of an anonymous observation too, and a reminder when a new reader is named. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Reclassifying during an investigation as a dated event with a reason; the rates followAn incident under investigation is moved to another class with a reason (a lost time injury needs at least one day lost); each change stays on the incident with the old class, the new class, the reason, the person and the day, and is written in the audit trail. LTIFR and TRIR read the class and the days lost, so they follow the new class; a move to the same class, a move without a reason and an incident outside an investigation are refused. Every step is one transaction with an audit entry. Story HSE-R3 (report 50, HS-17).Not yet: Not built (2026-10-28): re-evaluating a notification already given to an authority against the new class (the app never says whether one is due). Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Investigation team and evidence; a de-identified lesson from a completed investigationAn investigation takes a team (name and role, up to 12) and its evidence (text and reference, up to 30). From a completed investigation a lesson is raised: the text is refused if it holds the incident number, the company, the place, the person or the names of the team (case and Turkish letters are not told apart); the lesson opens as a draft in the Lessons learned register and keeps the incident number as its source; one lesson per investigation. Every step is one transaction with an audit entry. Story HSE-R4 (report 50, HS-18).Not yet: Not built (2026-10-28): sending the lesson to the company library by itself (the lesson has its own review flow) and de-identification that also finds hints other than names (an equipment number, a date). Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Notification prompts whose kinds and periods the project's legal owner sets, blank by defaultThe incident class, the days after the incident, who is told and the law, regulation or article the period comes from are set by the person an authority record names as the legal owner, with a fresh second factor; a rule is not saved without a source. With no rule there is no prompt; for every incident of a class that has a rule and whose notification is not recorded the page shows "upcoming", "today" or "overdue". The app sends nothing and does not decide whether a notification is required; a rule is withdrawn, never deleted. Every step is one transaction with an audit entry. Story HSE-R5 (report 50, HS-19).Not yet: Not built (2026-10-28): sending the prompt by e-mail (it is not in the daily notices yet) and a template of rules per country (no country profile has been decided). No legal advice is given. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Contractor HSE pre-qualification and the bridging matrixA company's HSE answers, documents, assessor and last day of validity are recorded (a subcontractor number is checked against the subcontractor record); the result starts "unknown" and the software gives no score. Only a person named as the HSE governance approver, other than the one who recorded the answers, gives the result with a reason and a fresh second factor (accepted or rejected); the answers of a decided record do not change and after the last day it reads "expired". The bridging matrix keeps, for each company and topic, the revision of the owner's and of the contractor's procedure and which one governs; an undecided topic stays "undecided". Every step is one transaction with an audit entry. Story HSE-R6 (report 50, HS-20).Not yet: Not built (2026-10-28): a pre-qualification and bridge card on the subcontractor's own page (today it is linked by subcontractor number from the HSE page) and a questionnaire template (the customer's form has not been received). Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Competence by job and permit kind, as a record; certificates verified or voidedA requirement from the customer's procedure (a job, an optional permit kind, the competences needed and the source procedure) is written as data; the "what is lacking" table lists the competences missing or run out for the people whose job it is (a record: it lets no one work and stops no one). Someone other than the person who entered a certificate verifies it; a certificate entered by mistake is not deleted but voided with a reason, keeps its row and no longer counts, and its scan is attached as a file. Every step is one transaction with an audit entry. Story HSE-R7 (report 50, HS-21).Not yet: Not built (2026-10-28): a daily e-mail reminder for a certificate about to run out (today it shows on the people page) and a check of the requirement when a permit is recorded (a permit record does not check competence). Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Significance of environmental aspects with a customer-approved method, and waste types from the customer's listThe appointed HSE manager records the significance method (levels, source document, who approved it for the customer, day) as a versioned record; with no method the app says "no approved method" and rates no aspect. With a method, each environmental control gets a level and a reason and the rating keeps the method version. Once the customer's waste types (code, name in two languages, whether a manifest is needed, source list) are loaded the waste register accepts only those and the manifest rule comes from the type; if every type is retired the built-in types apply again and old records do not change. Every step is one transaction with an audit entry. Story HSE-R8 (report 50, HS-22, HS-23).Not yet: Not built (2026-10-28): the authority permits and consents with their conditions (the second half of HS-22) and measured results with unit, method and laboratory against a versioned limit. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| HSE audits as a discipline of the audit programme; KPI definition versionsThe audit programme gained a discipline (quality or HSE) and the edition of the standard: an HSE audit cannot be planned without the standard and the edition it audits against, quality audits work as before, and the findings and the links to non-conformance reports and actions follow the same flow. The TRIR and LTIFR answer carries the version of its definition, its bases and which classes are counted; if the definition changes it gets a new version. Every step is one transaction with an audit entry. Story HSE-R9 (report 50, HS-24, HS-25).Not yet: Not built (2026-10-28): a page that sets the leading and the lagging indicators side by side on one review (the lists are in the definition, the page is not built) and an HSE audit checklist template. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Legal hold on a project's HSE records; the HSE evidence pack of an incident or a permit recordOnly the person named as the legal owner puts a legal hold on and lifts it, with a reason and a fresh second factor; while it is on, deleting the project (request and run) is refused and the HSE audit entries of the project are not archived out of the database; who put it on and who lifted it is recorded. The legal owner also sets the retention day, with the law or contract clause it comes from, and it is only ever extended: HSE records and the audit trail are kept until then, the project is not deleted before the day has passed or while it holds HSE records and no day is set, and closing a project deletes no HSE record. The project export carries every HSE table, every HSE file (its SHA-256 checked against the stored bytes) and the HSE audit trail, with a manifest. The evidence pack downloads the record of an incident, an observation or a permit record, its files (SHA-256, time taken, late mark) and its audit entries with a SHA-256 digest of each part and of the whole; the details of a restricted incident are hidden from anyone who is not a reader. Every step is one transaction with an audit entry. Story HSE-R10 (report 50, HS-26, HS-27).Not yet: Not built (2026-10-28): the pack as a zip that also holds the bytes of the files (today it holds their recorded digests) and the hold covering backups (today it covers deletion and the audit archive). No legal advice is given. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Management of change and the pre-start-up safety review (a person signs, nothing closes by itself)A change is opened with a title, a category, a description, the revision of the technical basis, the risk assessment (checked against the register), the affected documents and training; to submit it needs the technical basis and the assessment. Approval or rejection comes only from a person named as the HSE governance approver other than the one who raised the change, with a fresh second factor; implemented and close are taken with the person's note. The lines of the pre-start-up review come from the customer's procedure (there is no default list; they can be copied from a released checklist version); each line is marked met, not met or not applicable, and once every required line is met or approved not applicable another approver, not the author, signs; a change can have a checklist of its own. A "not applicable" line needs a reason, records who decided and when, and counts as resolved only when a second person (the HSE governance approver, other than the author and the one who marked it) approves it. An approved change or a signed review issues no commissioning certificate, ready-for-start-up declaration, start of work or permit and implies none. Open changes and unsigned reviews show as blockers and stop nothing. Every step is one transaction with an audit entry. Story HSE-R11 (report 50, HS-28, HS-29).Not yet: Not built (2026-10-28): tying the review to the readiness review and certificates of slice 117 (that slice is not on this branch; the records stand alone and the link is added when it arrives) and a separate authority matrix for the approvals. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| HSE in the handover pack, the drill interval as a project setting, recurring HSE inspections and the start gate as a readiness constraint (administrative)The HSE section of the handover pack counts the open HSE actions and observations, the permits recorded (those open at the source apart), the drills held, the state of training and the open start-up blockers; it does not say the site is safe. The drill interval is a project setting and while it is blank no drill shows as overdue; a drill is not proof of preparedness. A recurring HSE inspection (title, area, released checklist, interval, first day) works out its next day from the last day it was done with the day and state rules of the maintenance engine; recording it done is a person's act. When the start gate constraint is switched on in the project settings the missing HSE records show as an "HSE record" constraint in the work package readiness; it is an administrative check, not a permit to work or a safety approval, and it does not hold a package whose start was recorded. Every step is one transaction with an audit entry. Story HSE-R12 (report 50, HS-30, HS-31, HS-32, HS-33).Not yet: Not built (2026-10-28): putting this section into the handover dossier document (that document is not on this branch; the section has its own endpoint), recurring HSE inspections as a task kind in the maintenance plan table itself (today a separate table with the shared rules) and a phone reminder for a recurring inspection. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Records-only groundwork for a future ePTW (all Disabled): the procedure, overlap information, isolation certificates, shift entries and the validation packThe customer's permit procedure (document revision, kinds, longest validity, roles, form text) is stored as versioned data; storing it switches no mode on (the record and its audit entry are written with the mode unchanged). For recorded permits the overlap (the same place or work package, the same days, not closed at the source) is shown as information to whoever records a permit, gives no verdict, and "no overlap shown" does not mean safe; a coordinator who is neither the person who asked for nor the one who issued the permit records the review with their own reason. An isolation certificate is written as on the outside certificate, links the recorded permits it serves, and the release is recorded only when every linked permit is recorded as closed or cancelled at the source. "Released" there is only the state the outside certificate reported and a person recorded: it gives no authority to remove a physical isolation, verifies or restores nothing and is kept apart, with its own person and time, from the site verification; a shift entry is written under the signed-in account. All of these are refused while permits are Disabled, none changes a permit row, none issues, starts, suspends or closes a permit, and the former workflow paths stay closed to everyone. The validation pack lists the failure modes and the test that stands for each; it replaces no approval. Every step is one transaction with an audit entry. Story HSE-R13 (report 50, HS-34 to HS-38).Not yet: Not built (2026-10-28): the operational electronic permit to work (the app as the permit system), which needs an independent competent HSE assessment, a software safety verification and the customer's or operator's site approval, and the phone showing the time of the last synced state with "not valid offline". Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Customer approval of safety-critical HSE role assignments: the project manager proposes, the customer's approver activatesThe site or PTW responsible, the appointed HSE manager, the plan and assessment approvers, the governance approver, the legal owner and the health data reader are safety-critical roles (the list is data in the code, and a test fails if a new role is added without being classified; the health data reader's rights stay read only, but it opens restricted health and personal data, so it is assigned this way too since slice 123, and a record of it made before counts as proposed until approved). The project manager can only propose one, addressed to one of the customer's approvers; a proposal is inactive and counts for no approval, no Record Only vote and no authority check. The approvers are a record of their own, authorised beforehand by the customer's company administrator with the days and a customer reference (the project manager who proposes cannot set them up). The person who proposes, the person who receives the role and the person who approves are three different people (account, address and name, case and Turkish letters folded), and the approver cannot have been set up by the proposer. An approval or a refusal takes a reason and a fresh second-factor code; approving never switches Record Only on and is not one of its two approvals. Assignments are per project and are listed as proposed, active, refused or revoked with their history; revoking one ends it at once, voids a vote it gave that was pending, and takes an open Record Only back to Disabled (with an audit entry and a note on the page) when it was one of the two people that mode stands on. Proposals addressed to a revoked approver that were not yet approved are voided; assignments it approved before stay. Critical assignments made before this rule are kept, marked as assigned before approval was required, and count as proposed until approved. The rules are enforced on the server and tested through the API, including requests that arrive at the same moment and authority held in another project.Not yet: Not built (2026-10-29): a notice by e-mail to the approver and a joint approval by several approvers. These decisions are not an approval of live site use. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Organisation chart and positions, and the monthly staffing plan set against the people mobilised and the programmeA position has a code, title, discipline, organisation, the position it reports to (never itself or one below it), a first and last planned day and the competencies it asks for; the chart is listed as an indented tree. A person of the HSE register holds the position: if they lack a competency it asks for, it has expired, or they already hold another position, a warning shows and the position is filled with a reason, which is kept with the warnings in the audit trail. A position nobody holds whose first day has come is late, with the days; cancelling needs a reason, releases the holder and moves the positions below to the top. The staffing plan is the number of people planned for a role or trade in a month (one number can be written for a range of months); mobilised are the people on the Personnel page who are on site in that month and whose trade is written as the role; the gap and the months short show on the row, beside the first and last day of the latest imported programme and the number of activities running each month, and months outside the programme are marked. Each step is one transaction with an audit entry.Not yet: Not built (2026-10-28): a drawn chart (boxes, print, PDF), taking positions in from an HR system or Excel, working the need out from a resource-loaded programme (the XER resource assignments are not read; the number is typed), a defined trade list instead of matching a person to a role by the trade text, an approval flow and an Excel file for the plan. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Personnel arrival and departure, certificates with expiry (shared with HSE inductions), training records and the expiry watchA person is the same record as on the HSE page: name, company, trade and badge number, with no identity number field. Arrival and departure periods: a person is on site in one period at a time, an overlapping one is refused, the departure day can be written later, a period can be tied to a position; the state (planned, on site, demobilised, never mobilised) is worked out each time and those leaving within two weeks are counted. A certificate is the HSE competency record (induction, work at height, confined space, hot work, electrical, first aid, lifting, scaffolding, fire warden and other certificates with a name) and shows on both pages. A training record has the training, provider, day, hours, result (passed, attended, failed), expiry day and certificate number; one session is written for many people in one transaction, and a failed training does not expire and does not count in the hours. The expiry watch lists every certificate and training that has run out or runs out within 60 days, counting only the latest of each kind per person, so a renewed one takes the place of the one it renews. Each step is one transaction with an audit entry.Not yet: Not built (2026-10-28): checking a certificate with the issuing body's register (needs access to an outside body), attaching a scan of the certificate as a file, an e-mail reminder for a certificate about to expire (not wired to the daily notices), a competency matrix per position or trade, taking people and certificates in from Excel, and HR data such as contracts, pay, visas and work permits (left out on purpose). Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Timesheets: hours of a person or a crew against a work package, approval, a proposal from the daily report, and handover to payroll as a file or through an adapterA crew has a name, company, trade, foreman and people. An entry is a person's or a crew's (those who were there are ticked) day, work package (or indirect hours with the reason written), hours for each person and the overtime in it, in quarter hours; a person's day is refused past 24 hours across all entries and flagged past 14, and the work package must exist and not be cancelled. Draft, submitted, approved, rejected, sent to payroll: someone other than the one who entered the hours approves, a rejection needs a reason, approved and sent hours do not change and are not deleted, and in a batch step if one is refused none is applied. Approved hours by work package and by person. Proposal from the daily report: the manpower line of a signed or locked report becomes the hours of the crew whose company and trade are written the same, with the work package when the report's work lines name exactly one; a report gives a headcount, not names, so a crew of another size cannot be saved until who was there is chosen; the proposals are saved as drafts. Payroll: the approved hours of a period become rows for each person, day and work package (badge number, name, company, day, package, kind, regular and overtime hours, timesheet number; crews are spread to their people) in two CSV formats (comma and decimal point, or semicolon and decimal comma); people with no badge number stop the batch with a warning, the file stays downloadable exactly as made, and the hours are marked sent. An interface for an adapter that writes to a payroll system (it builds the file, may deliver it and takes a reference back) is defined and tested with a fake one: if delivery fails the hours are approved again and the batch is kept as failed; a batch made in error is voided with a reason and its hours are approved again. Each step is one transaction with an audit entry.Not yet: Not built (2026-10-28): an adapter for a real payroll or ERP system such as SAP, Logo or Mikro (the customer's system, its interface and access were not obtained, so the file is the path that works today), pay, overtime multipliers and allowances (left out on purpose: Lintara keeps the hours and payroll works out the pay), entering hours on the phone without signal, clocking in by gate or location, leave and absence, taking hours in from Excel, posting hours to cost codes or earned value, and proposing the HSE hours (LTIFR) from approved timesheets (they still come from the daily reports). Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| Equipment and fleet: register, allocation to work fronts, hours of use and utilisation, service by hours or days, and certificatesA machine has a code, name, category (crane, excavator, loader, truck, concrete pump, generator, compressor, access platform, forklift, welding set, other), ownership (own, hired, subcontractor's) and owning company, make, model, serial number, plate, the day it came to and left site and the meter on arrival; its state is active, out of service or off site. A certificate (periodic inspection, load test, registration, insurance, calibration or a named one) has an expiry day, and a renewal takes the place of the old one; the certificates expected by category (inspection and load test for a crane, inspection for a forklift and an access platform, registration for a truck, inspection for a concrete pump) are a starting list and a warning, not a lock. Allocation to a work front has a work package, days and an operator; a machine is at one front at a time (an overlapping allocation is refused); a machine out of service, a certificate that is missing or runs out before the allocation ends, and an operator without the competency needed (lifting for a crane and a forklift, work at height for an access platform) warn, the allocation is made with a reason, and the warnings are kept with it. Hours of use: hours worked and broken down each day and the meter at the end of the day, which only goes up; writing a day again replaces it; when the equipment line of a signed daily report carries the equipment code, the day's hours are proposed. Utilisation is hours worked over possible hours (working days on site times the shift, on the project calendar) and availability the share not broken down. Service is set by running hours, by days or both; the next date comes from the last service (from the day it came to site if never done) and the machine's work over the last 30 days, and shows as due soon within 14 days or a tenth of the hours interval, and overdue past it; a service done is recorded with day, meter and who did it. A list of service and certificates due and the overall counts. Each step is one transaction with an audit entry.Not yet: Not built (2026-10-28): posting hire rates, fuel and the cost per hour to cost codes, taking machine data in from telematics or GPS (the customer's devices and their interface were not obtained; the OPC UA reader is for plant data), fuel consumption, spare parts and work orders, attaching a scan of an inspection certificate, scanning a QR code on a machine, and the shift length as a project setting (it is typed on the page, default 8). Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| HSE acceptance verification: ratings that keep their scale, anonymous observations that stay anonymous, refused reads logged (slice 123)Six points the partners asked to see proved by server-level tests before technical acceptance. The health data reader, the governance approver and the legal owner are assigned only by the customer-approved route, are inactive until approved, have no effect in another project and stop at once when revoked; the next read of a revoked health data reader is refused and written in the read log. A rating always carries the scale it was given under (the former default scale, or a matrix and its version): after a new matrix is approved the old ratings keep their own scale and label and read 'not rated under this scale', the hazard counts are given per scale, a rerate takes the likelihood and severity again and the old rating stays in the history of the record. On an anonymous observation the submitter's name reaches no ordinary reader, list, picture list, export, evidence pack or audit trail view; it is shown only to the named health data readers and each opening is logged. Slice 125 followed it up (2026-10-30): the customer's approver is mailed when a critical role is proposed to them and the proposer when it is decided (the message links to the page and approves nothing); the legal owner is mailed 90, 30 and 7 days before a retention day and can set a retention day for each kind of record (a blank kind is kept); the files of a project under a legal hold are never removed from the backups and the restore test looks for such projects in the backup; database backups that carry a project under a legal hold are not pruned while the hold stands, and a restore drill (restore-test.sh --drill) checks each such project's HSE rows, audit entries and files (SHA-256) in the restored database; a server tool reads a project export and checks every HSE row, file (SHA-256) and audit entry against its manifest, reporting what a restore would bring back. Retention, the legal hold, the project export and the isolation release are described in their own rows. These tests are evidence of behaviour, not final technical acceptance and not an approval of live site use.Not yet: Not built (2026-10-30): the same tests against a PostgreSQL server with many connections (they run on PGlite), the unreviewed Arabic and Russian words of the new texts, a restore itself (the export check reports what one would bring back), and a legal hold that keeps older dumps out of the backup rotation. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
Handover and assets · 31
| Document, tag and equipment link on one card ★Shows each tag on one card with its class, status, system, area, parent and tags under it, its property values, the equipment under it (manufacturer, model, serial number) and the documents that describe it, each with its stage and whether it is final. The same card holds the tag's aliases and the owner's SAP or EAMS number, its 14 CFIHOS fields and those of its equipment, its link to the owner's maintenance system (the system's number and status, differences still open) and its maintenance: the tasks with the interval and whether each date comes from the meter or the interval, the running-hour readings and the work-order history. | Common In enterprise suites | In the app |
| Tag register and class libraryKeeps the tag register: tag number, class, description, system, area, status and parent tag, with equipment under a tag and links to documents by document number. A project profile holds 13 common classes (pump, valve, motor, instrument, tank and more) with the properties each has to carry and the unit it is given in; the project edits it, and a class taken out of it never deletes a tag. The register is read from and written to Excel. A tag also carries aliases, a vendor number and the employer's SAP or EAMS number (each finds the tag, no two tags share one), and the CFIHOS reference data library or the employer's own RDL is read from an Excel file as a class library: shown first, added to the profile with its library ids, never overwriting what the project edited, and never making a property mandatory that the file does not say is.Not yet: Tag-to-tag physical connections (they come from design tools) are not built. | Common In enterprise suites | Partly in the app |
| CFIHOS import and export with project profile ★Imports and exports CFIHOS data, with a project profile of about 40-60 classes, the employer's reference data library from Excel, and tag and equipment field sets. The app already reads and writes the register as an Excel workbook in a CFIHOS style (tags, equipment, tag documents and property values, English or Turkish headers, an export reads back in) against a project profile you edit, and never assumes every property is mandatory. The exchange file in the CFIHOS layout carries the 21 tag fields (9 mandatory) under their CFIHOS names, the 17 equipment fields (2 mandatory), the tag aliases, the linked documents and the property values, and reads back, in our own file and in sheets named after the CFIHOS entities. The employer's RDL is read from Excel into the profile. With the CFIHOS record switched on, handover checks H14 and H15 say which mandatory field of a tag or an equipment is empty, which critical flag is not yes or no, and which equipment dates or prices are wrong. The company keeps a versioned CFIHOS library: the Core V2.0, Extended 2.0.0 and 1.4, 1.5 and 1.5.1 reference data library workbooks (or the employer's Excel library) are imported once and kept with their version, file name, SHA-256 and import record; a project picks classes from one version and its profile records which. The register is also written and read back in the sheet and column names of the CFIHOS V2.0 data dictionary, and everything the register cannot keep is listed as a typed exception. Handover checks H16 to H18 test the linked documents against the library (CFIHOS document type, the documents the class asks for, document master fields) when the profile took a library version; H13 to H15 are unchanged. The project can pick one of the six CFIHOS contract scenarios: the exchange file then holds only what the contractor delivers, the checks of entities the scenario marks Not Applicable do not run, and check H19 asks a tag for the properties, equipment and document links the scenario asks for. The CFIHOS CSV package is imported through the same reader as the Excel file, and a project can move from one library version to another by a plan that shows every class and property change first and leaves tags and values untouched. The Extended library's source standard document requirements are stored, and a class picked from it with its documents asks for the documents its source standards ask for. The owner's file in the CFIHOS layout (sheets TAG, TAG PROPERTY, EQUIPMENT, DOCUMENT REVISION TAG REFERENCE, or a plain tag list) is read and compared with the register: tags missing either way, class, process unit and status differences, the property values the owner fixed, expected equipment and documents, also as an Excel file; nothing is stored and nothing in the register changes. Check H20 tests the linked documents against the status the handover event asks (the project writes which of its stages stands for each library status), H21 the mandatory attributes of a document revision the register has a field for, and H22 the dictionary's attributes of company, purchase order, order item and model part that the contract scenario has the contractor deliver. Lintara is not CFIHOS certified or conformant.Not yet: The other entities of the scenario template (plant breakdown, physical connections, class and property entities) are not checked and the owner's file is not taken in as records; H21 and H22 cannot test attributes the register has no field for (storage media, regulatory indicator, company contact, order date and description); CFIHOS 1.2 and 1.3 are not published, so the tests use 1.4, 1.5 and 1.5.1. Nothing is declared in the CFIHOS conformance database. | Rare In enterprise suites | Partly in the app |
| Contractor-side handover pre-check (completeness, consistency, compliance) ★Checks every tag before the register goes to the employer: tag numbers unique (also when only case, spaces or separators differ), tag format and the project's number mask, mandatory fields filled, class and status known to the project, parent tag present with no loop, required properties of the class filled, no TBD or N/A in required fields, numbers that are numbers with the right unit, equipment with manufacturer, model and serial number (and no serial number twice), and linked documents that exist and are at a final stage. A report per system counts the tags and checks passing and failing, shows the failures by rule in English and Turkish, and flags open category A punch items. Equipment dates must be days in the order of purchase, installation, start-up and warranty end. Each delivery is kept as a snapshot and the next says which tags were added, deleted, renumbered and modified and which part moved, with a change list as CSV. The employer's own rule pack is loaded as a JSON file of rules (a field, classes and one test each, with the employer's own rule id) and the register is run against it.Not yet: Checks that read the content of a document, such as the same value on the P&ID and the datasheet, are not built. | Rare | Partly in the app |
| Maintenance plan from handover data ★Builds a maintenance plan for the tags that have been handed over, from task templates per tag class: the task, the interval in days or running hours, the trade, estimated hours and spares. The app ships 18 starting templates for ten of the thirteen default classes (pump, compressor, fan, motor, control valve, transmitter, pressure vessel, heat exchanger, transformer, switchgear); the project admin edits them to the manufacturer's manual, and a class with no template is listed with its tags. Generating the plan adds a task row for every handed-over tag and template, counted from the handover day you give; later runs bring rows up to date with a changed template and never delete one. Running hours become days through the hours a tag runs in a day (a project figure, or one per tag; a tag that does not run gets no date). The Maintenance page shows the plan by system, what is overdue or due in the next 30 days, and the tags with no template; a task is recorded as done on a day and the next date counts from it. The plan downloads as Excel and as a CSV with 19 fixed columns for a maintenance system's import, and in the layout of SAP PM (functional locations, equipment, maintenance items) and Maximo (locations, assets, preventive maintenance). Running-hour meter readings date the tasks counted in hours (the meter when last done plus the interval, at the machine's own rate), work orders are typed or read from the maintenance system's list, the interval is shortened by a factor for safety or production critical tags, and a manufacturer's figure for the make and model installed replaces the template's, with the manual it comes from. Templates can also be proposed from an IOM manual by the AI, a task at a time, each accepted by the administrator (see the DEXPI and manuals entry). | Not found elsewhere | In the app |
| System-by-system handover; SAP PM and Maximo filesHands over by system and produces files for SAP PM and Maximo. Each system is reported on the Handover page (tag data passing or failing, open category A punch items, open non-conformance reports) and printed. A system is offered to the owner, accepted by the owner's person or returned; offering one that is not ready needs a reason that is kept with what was open, an acceptance can set the tags to handed over (a return puts the status back), an event can name one of the five CFIHOS handover events, and each event keeps what was handed over that day. The SAP PM and Maximo load files are produced for one system or all. | Rare In enterprise suites | In the app |
| Completion scheme: sheet classes and the certificates that close a system or subsystem, with their order, what each needs and who signs, as the project's own data (WBS 6.3, 6.4)The Completion scheme page keeps the project's check sheet classes and certificates as an ordered list. A sheet class has a code, a name in two languages, a phase (construction, pre-commissioning, commissioning) and aliases; A, B and C are the project's template classes, not the rule of one standard. A certificate has a short name, a name in two languages, a system or subsystem level, the sheet classes it needs, the earlier certificates it needs, the punch categories that stop it while open, a ladder of signatures (a role name and a side: contractor, owner, operator, third party) and an optional review step (a name and the side that reviews; only a label, and the meaning of the name "cross examination" is not interpreted until the operator's own workflow confirms it). The scheme also keeps the days of notice for witness and hold points. Five starting points (generic, NORSOK-style, PDO-style, OPERCOM-style, Turkish public works) are written in our own words and follow the placement table of report 48; none is the text of a standard or a company procedure. The scheme is versioned: a draft changes freely and is inactive, it stops nothing; adopting needs who approved it for the customer (a typed name), where the approval is recorded and the day it applies from, and a fresh second factor; an adopted version never changes, a change is a new version applying from a later day. The version in force is the latest adopted version whose day has come; with none, nothing is stopped on a scheme (off by default). The administrator who adopted it and the approval are in the audit trail. Only the project administrator writes the scheme; the contractor's own people read it.Not yet: The one thing that works from the scheme today: once a scheme is adopted, inspections are raised only from a released version of a test plan (CM-03). Certificates, the gate calculation and punch stopping a certificate now work from the scheme (the two rows below). Signing authority per person and the reassessment of a signed certificate now work (rows below). Not built (2026-10-29): opening the scheme to the owner's, subcontractors' and third parties' people; a real customer's certificate sequence and signers (decision D08 is open); loading a scheme from Excel. It has not been tried on a real project. | Common In enterprise suites | Partly in the app |
| Systems and subsystems: boundary, drawings pinned at their revision and file digest, executor and lead, one system and one subsystem per tag, a system list from Excel, readiness read from the records (WBS 6.3)A system is the text the tags already carry in their system field (there is no second list; spelling without regard to case or spacing); a unit's details add only what the text cannot say: operational or not, the boundary in words, the boundary drawings, the executing company, the lead and a planned day for each certificate of the adopted scheme. A boundary drawing is chosen by any number of the document; it is pinned at its current or the asked revision with the SHA-256 of the file at that revision (there is no separate revision table; a later revision does not move the pin, and a revision with no file is refused). A subsystem belongs to a system; a tag is in one system and in at most one subsystem of it, a tag of another system cannot be put in, a bulk assignment is all or none, and a tag that changes its system leaves its subsystem, which the audit entry says. The readiness table is read from the records and no number is typed: tags, tags handed over, subsystems, check sheets signed and passed (the system's own and its tags'), failed sheets, open punch A, B and C of the system (the categories the adopted scheme stops on, or only A without one), open non-conformance reports; a failed sheet, an open punch item or an open report shows the unit as blocked with the reason, all sheets signed and passed shows it complete. A list of systems from Excel (Code, Parent, Kind, Boundary, Executor, Lead; Turkish or English headers) is read first: each row shows new, changes or same and refused rows show their line number; nothing is written while a row is refused and applying is one transaction. The contractor's own people read it and administrators, controllers and planners write it; the owner's, subcontractors' and vendors' people have no access. The table issues no certificate.Not yet: Not built (2026-10-29): punch and NCR counts on a subsystem row (a punch item carries no tag yet, CM-08); a sheet against a whole subsystem (a sheet is bound to its tag, CM-05, but there is no inspection subject kind of subsystem); marking up a P&ID in the app (a drawing is linked as a document); an Excel export of the table; mapping to the CFIHOS class library (the CFIHOS slice did not run before this one). It has not been tried on a real project. | Common In enterprise suites | Partly in the app |
| Test plans as controlled records: phase, source of the criteria, released versions; measurement steps with unit, sourced limit, instrument and calibration; retest of a failed inspection (WBS 6.3, 6.4)A test plan is a draft until a person releases it. It belongs to a phase (construction, pre-commissioning, commissioning, FAT, FIT, SAT, SIT, loop check) and says where its acceptance criteria come from (a specification, a standard with its edition, a vendor or owner procedure, or our own skeleton to be confirmed by the project); a plan with no phase or no source cannot be released. Releasing writes a version once, with who released it, the day and the SHA-256 of the steps; a released version never changes, and changing the steps, the phase or the source of a plan moves it to the next version as a draft. Once a completion scheme is adopted, an inspection is raised only from the latest released version and says which version it came from; with no scheme adopted nothing changes. A step can be a measurement: a unit, a kind of limit (range, at least, at most, or only record), the limits and the source of the limit (a limit with no source is refused). In an inspection the value is written with its instrument and calibration reference; no unit is converted, a measurement step cannot pass without a value, a pass cannot be recorded for a value outside a limit, and the software only suggests a fail for such a value: it never proposes or sets a pass, and gives neither pass nor fail for a value with no limit. A done or signed inspection with a failed step is retested by a new inspection from the same plan version with no results, linked to it; the failed record never changes, a failed retest is retested in turn and the chain reads from either end. Every change is one transaction with an audit entry; a refused call writes none.Not yet: Not built (2026-10-29): entering a measured value on the phone's offline path; the CSV of an inspection with its values (its PDF is built, see the printable sheet row); a test file attached to a step; who may release a plan is open (decision D03), today the quality writers; drafting a plan from a vendor manual with AI (CM-28). It has not been tried on a real project. | Common In enterprise suites | Partly in the app |
| Equipment replacement under a stable tag; check sheets generated from the tag class matrix and bound to the tag (WBS 6.3)On the tag card a unit of equipment is replaced with "Replace": the new code, serial number, day and reason are written, and a serial that did not change is refused because it is the same item. The tag keeps its id, number, system and every record on it; the unit taken out stays under the tag as history with its day and reason, cannot be edited or deleted, and cannot come back through an Excel row. The handover checks, the Excel file, the EAM mapping and the maintenance plan read only the equipment in service. In the tag profile each class lists the test plan its tags are checked with, one per phase. On the Systems page, for a system or subsystem, a preview (nothing written) shows what would be made; applying raises one inspection of each listed plan for each tag, in one transaction, bound to the tag and with an audit entry each. A sheet that exists is not made again; a plan that does not exist, is retired, is in another phase or has no released version while a scheme is adopted is skipped with the reason; no result is filled in. An inspection of a tag raised by hand is bound to the register's tag too.Not yet: Not built (2026-10-29): a sheet against a whole subsystem (an inspection subject kind of subsystem); loading the class matrix from Excel (CM-24); assigning a matrix from the CFIHOS class library; the installation day of equipment recorded before replacements existed is unknown. It has not been tried on a real project. | Common In enterprise suites | Partly in the app |
| Punch item: tag, discipline, stage found, raising company, an extra condition, the owner's waiver and a linked reopening (WBS 6.3, 6.4)A punch item may carry the tag it is about (kept as the register spells it and bound to the register, a tag that is not in the register is refused, there is no second list of tags; an item raised from a failed inspection step takes the inspection's tag and discipline), a discipline, the stage it was found at (construction, FAT, test, cross examination, commissioning; cross examination is only a label) and the company that raised it. They change while the item is open, with the old values in the audit entry, and are listed, filtered and exported to Excel. "Also to clear before" holds an item back from the certificates picked from the adopted scheme, with who, when and why: it only adds, it never removes what the category stops, and it is refused while no scheme is adopted. The owner's waiver: the owner's person (a typed name) accepts the item as it is for named certificates, with the reference of their record, a reason and a last day; it is given only for certificates the item already holds back (a waiver that changes no gate is refused), the item stays open, an expired waiver lifts nothing, one waiver at a time, taking it back needs a reason, and the project admin records both with a second factor. A verified or closed item never changes: if the problem returns a new item that points back at it is raised (the category may change), the old item's audit entry says it was reopened, and one reopening can be outstanding at a time. The opening, a category change, the closing and the reopening are in an audit trail the application cannot change or delete; a refused call is not written.Not yet: Not built (2026-10-29): the new fields on the phone's offline path; a tag typed by hand that is not in the register is not accepted; a hold point is never waived and the witness and hold notices are not built (CM-09); the owner's own people cannot write a waiver themselves, the project admin records it (CM-10). It has not been tried on a real project. | Common In enterprise suites | Partly in the app |
| Certificate gate and completion certificates: a gate computed from the records, frozen contents, a signing ladder, voiding (WBS 6.3, 6.4)On the Systems page the panel of a system or subsystem shows, for each certificate of the adopted scheme at that level, whether its gate is open and, if not, every reason with its number. It is computed from the records each time, never typed, and writes nothing. What blocks: no tags; no check sheet of a class the certificate needs; a sheet that is not signed, failed, or signed with steps without a result (a failed sheet that a retest answers no longer counts, the end of the chain does); an earlier certificate not signed; an open punch item that the scheme's category rule or "Also to clear before" holds against the certificate (rolled-over, verified, closed and waived items do not count, the ones lifted by a waiver are listed apart, an expired waiver is no longer counted). With no adopted scheme there is no gate and nothing is blocked. A certificate is a draft made only while the gate is open (by the site team); what it rests on is frozen into it (tags, sheets with plan number, version and outcome, open and waived punch items, pinned boundary drawings) with a SHA-256 re-checked on every read. Signatures follow the scheme's ladder in order, by the named person who holds the role, recorded by the project admin with a second factor; the last signature issues the certificate only if the gate still holds at that moment, otherwise nothing is written and the blockers come back. A partly signed draft does not count as signed, so the next certificate keeps waiting; an open gate or a finished test never makes one by itself. A signed certificate is never edited or deleted, it is voided with a reason and a new one can be made. Under a signed certificate the frozen contents are compared with the records today (tags, sheets, punch items, waivers that ran out, drawing revisions) and the gate of its kind is read as it stands now; it is only a reading, nothing is voided, written or opened (CM-17). The draft also freezes the document, revision and file digest each sheet rests on (T01). The making, every signature, the issue and the voiding are in the audit trail. No AI or agent path exists, and a guard test checks the code for it.Not yet: Not built (2026-10-29): the owner's, subcontractors' and third parties' own signing of certificate steps (the certificate routes are closed to outside parties; CM-10 covered inspection points and punch verification only); the review step as a record (CM-18); the system dossier (CM-22), so the traceability test T05 holds only as far as the frozen contents; a reassessment opens no notice or work item; open non-conformances are not counted by the gate because the scheme does not name them. A real customer's certificate sequence and signers are not known (decision D08). It has not been tried on a real project. | Common In enterprise suites | Partly in the app |
| Witness and hold notices and the no-show record (WBS 6.3, 6.4)In the inspection panel a person records that the owner or the third party was told about the steps that have a witness or hold point: the steps, the planned day, the day it was sent and to whom, the acknowledgement if the party answered, the no-show if the party did not come (not before the planned day); a wrong notice is withdrawn with a reason, never deleted. Lintara sends nothing. The steps with no notice are listed. With a completion scheme adopted, "told, did not attend" on a witness point is recorded only for that step and party on a notice given at least the scheme's notice days ahead with the no-show written on it, and the record keeps which notice it rests on; with no scheme nothing is asked (the default is off). A hold point is never waived, with or without a notice and a no-show: it stays open and the inspection cannot be signed until the point is signed (AT-019, AT-NEG-003, decision D14). A refused call is not written to the audit trail; notices, acknowledgements, no-shows and withdrawals are. The owner's and a third party's own people acknowledge a notice sent to them with their own account (CM-10).Not yet: Not built (2026-10-29): sending the notice by e-mail or SMS (a person tells the party and records it); the notice period counts calendar days, not working days; not on the phone's offline path. It has not been tried on a real project. | Common In enterprise suites | Partly in the app |
| Signing authority: who may sign a certificate step, between which days (WBS 6.3, 6.4)On the Completion scheme page the project admin, with a second factor, records for a person (a typed name) the authority to sign one step of one certificate of the adopted scheme: the first day, an optional last day, where the delegation is written down and why. A step with no record is signed as before (the default is off); the first record checks the step, and a name whose authority is not in force on the day of the signature is refused with nothing written, the refusal naming who has authority that day (AT-002). A signature and its audit entry carry the authority they rested on. Names match without regard to case or spacing, I, İ, ı and i are one letter, and Şahin and Sahin are two people. An authority is taken back with a reason, never deleted, and the step stays checked even when the last authority is taken back, so taking back never opens a step to everyone. Recording and taking back are in the audit trail. Certificate signing, voiding and a punch waiver also ask for the second factor on screen.Not yet: Not built (2026-10-29): the person with authority has no account to sign with, the admin records the signature (the certificate routes are closed to outside parties); one person can hold authority on both the contractor's and the owner's step; no AI or agent can hold or use an authority, because the record is a typed name and no signing path exists for them; a real customer's authority matrix is not known (decision D08). It has not been tried on a real project. | Common In enterprise suites | Partly in the app |
| The exact revision of the document a check sheet rests on, and the impact review on a new revision (WBS 6.3, 6.4)A planned inspection pins the documents it is done against at the exact revision and the SHA-256 of the file at that revision (the same pin as a boundary drawing, no separate revision table). An older revision is allowed only as a controlled exception with a written reason, otherwise it is refused and nothing is written (AT-NEG-002); the list is fixed once the inspection is done. When a document moves to a new revision, the inspections that rest on the old one are listed in a queue computed from the register and the pins each time (so a revision that arrives by import or a bulk change is not missed) and in the inspection panel; a person decides what it means (no effect, retest required, new procedure needed, other) and writes why. The decision is written once beside the record: the inspection's results, signatures and state do not change (AT-009); a still newer revision asks again; a controlled exception is not listed while the revision it was taken against is current. With a scheme adopted an inspection with no decision stops the gate of a certificate, and a certificate draft freezes the document, revision and file digest of each sheet and keeps them when the document moves on (the partners' test T01).Not yet: Not built (2026-10-29): the decisions "retest required" and "new procedure needed" are shown but do not stop the gate and do not raise a retest; no notice or work item is opened when a document moves; an offline inspection done on a stale document (AT-NEG-014) shows in the queue but is not put to the person as a conflict at sync; the current revision of the document counts as the applicable one, there is no separate approval status; not on the phone's offline path. It has not been tried on a real project. | Common In enterprise suites | Partly in the app |
| Completion status report: system status, certificate register and punch clearance as one Excel file (WBS 6.3, 6.4)From the Systems page one Excel file in Turkish, English or both together: "System status" is read from the same records as the table on the page (tags, handed-over tags, check sheets, open punch A, B and C, open non-conformance reports, the status and why it is blocked, the executor and the lead); "Certificate register" lists the number, certificate, system, state, issue day, signatures, scheme version, the SHA-256 of the frozen contents and whether it is intact, and the reason if voided; "Punch clearance" counts per system, stage found and category the items open, awaiting verification, cleared, rolled over and lifted by a waiver (still open), with a total. Every number is counted from the records, none is typed; anyone who can see the page downloads it and the download writes nothing.Not yet: Not built (2026-10-29): a PDF version; a trend or a date range (the report is today's state); the names of the signers in the register (only the count). It has not been tried on a real project. | Common In enterprise suites | Partly in the app |
| Printable inspection sheet and completion certificate as PDF (WBS 6.3, 6.4)From the panel of an inspection the sheet as a PDF in Turkish or English: the test plan and its version, the subject, the location, the state, who did it and who signed it; for each step the criteria, the point each party holds and its signature, the result, the measured value (with unit, instrument and calibration reference) and the remark. A step with no result prints an empty cell to be filled in by hand on site; the software invents no result. The certificate PDF is under the certificate on the Systems page: the signing steps (who, which day), the frozen check sheets with their plan version and the documents they were done on, the punch still open and the punch lifted by a waiver, the boundary drawings and the SHA-256 digest of the frozen contents and whether it is intact; the PDF of a draft or void certificate says so under the title, so a paper copy cannot stand in for an issued certificate. Anyone who can see the inspection or the certificate downloads it and the download writes nothing.Not yet: Not built (2026-10-29): a QR code on the sheet; a CSV of the measured values; a bulk output as part of the system dossier (CM-22); the print layout has not been compared with a customer's own form. It has not been tried on a real project. | Common In enterprise suites | Partly in the app |
| FAT, FIT, SAT, SIT and loop check skeletons, and a sheet against a purchase order line (WBS 6.3, 6.4)On the Test plans tab one button adds five draft plans, one for each of FAT, FIT, SAT, SIT and the loop check, written in our own words with the basis "our own skeleton". A skeleton says what is checked and where a limit is to be read from; it writes no limit, tolerance or acceptance value (a test checks that no criterion contains a number), never says that anything passes, and leaves the hold and witness points to the project. A person reads it, writes the limits and their source on the steps and releases it. A phase that already has a skeleton is skipped and said. In the API an inspection raised from a FAT, FIT, SAT or SIT plan can be raised against a line of a purchase order (a line of the same project, not cancelled); a loop check or a construction check cannot. Each plan is made with its own number and audit entry.Not yet: Not built (2026-10-29): the purchase order line field on the screen (API only); the line's tag does not fill the subject by itself; the skeletons have not been reviewed by a specialist or on a real project; a vendor's own person cannot fill in a FAT sheet from their account (CM-10). It has not been tried on a real project. | Common In enterprise suites | Partly in the app |
| A retry key, a request id and completion events for webhooks (WBS 6.3, 6.4; platform)Every API request gets an id made by the server (a header the client sends is not trusted): it is on the response in x-request-id, in the body of an error and in the request_id column of every audit entry the request writes; it is a column of its own because the audit table accepts inserts only. A server error shows the first eight letters of the id in its message. The calls that create an inspection, a punch item or a certificate take an optional Idempotency-Key (8 to 100 characters): a call that comes again with the same key gets the first call's record back (200, idempotent-replay: true) and no second record and no second audit entry is written; a call the server refuses does not use up the key; a key belongs to one person and one kind of record. Webhooks have three new kinds: inspection signed, certificate issued and certificate voided; the message carries only the record's number, outcome and link (no steps, subject or voiding reason) and people on the owner's side do not hear them.Not yet: Not built (2026-10-29): the request id is not yet written on audit entries whose actor is spelled out by hand (such as sign-ins); every service's own copy of the audit helper was moved to the shared one, but nothing stops a new module from writing its own again; keys do not expire; there are no event kinds for punch closing and the like. It has not been tried on a real project. | Common In enterprise suites | Partly in the app |
| Commissioning procedures: certificates to be signed first, and permit references (WBS 6.3, 6.4)A test plan says which certificates (keys of the adopted scheme) must be signed before it is finished and which permit kinds it expects a reference of; the prerequisites are released with the plan version and changing them makes a released plan a new draft version. In the inspection panel each certificate is read from the records as signed or not for that system (a draft or half signed certificate does not count) and Done is refused, with nothing written to the audit trail, until they are met. With no completion scheme adopted nothing is applied (off by default); an inspection raised against an area cannot satisfy a certificate prerequisite. For a permit only a reference is recorded: the number, where it comes from (the system or the paper book, free text, no default source), an optional document reference, who recorded it and when; a wrong one is withdrawn with a reason and kept, and every step is in the audit trail. Lintara does not issue, start or close a permit and does not read its status; a reference on file does not show that work is safe, and a missing one is only a note that does not stop the procedure (the partners' decisions of 2026-10-28, Q4 and Q5). The HSE module was not touched.Not yet: Not built (2026-10-29): a comparison of the reference with the permit's state in its own system (it will not be built without the partners' approval); whether a missing permit reference should stop a procedure is to be agreed with the customer; the screen lists certificate keys only. It has not been tried on a real project. | Common In enterprise suites | Partly in the app |
| The dossier of a certificate: traced to sheets, document revisions and punch (WBS 6.3, 6.4)Under a signed certificate a Dossier line gives a manifest that runs from the certificate to each check sheet (and the plan version it came from), to the number, revision and file digest of the document each sheet was done against, to the punch items still open or lifted by a waiver, the boundary drawings, the signatures and the earlier certificates the kind needs, with the SHA-256 digest of the dossier. It downloads as CSV (opens in Excel, the digest is in its first lines) and as JSON. It is made only from the contents frozen into the certificate, never from today's records: if a document later moves to a new revision or a new punch item opens, the same certificate still gives the same dossier and digest (a test checks it); the certificate's reading gives today's state. A sheet that names no document, a draft or void certificate, and a record changed outside the application are said as notes or problems. Reading the dossier writes nothing to the audit trail, and the contractor's own side reads it.Not yet: Not built (2026-10-29): the documents' own files are not packed (only number, revision and digest); no PDF or zip; the dossier is not yet tied to the staged handover event (its digest is not stored there); today's digest of a document's file is not compared with the frozen one to catch tampered evidence; the owner's people cannot open it. It has not been tried on a real project. | Common In enterprise suites | Partly in the app |
| Import a test plan library from Excel (WBS 6.3, 6.4)On the Test plans tab, "Import a plan library from Excel" reads a sheet with one row per step (plan, discipline, phase, source of the criteria and its reference, step, acceptance criteria, reference, unit, min, max, limit source, a point for each party; Turkish or English headers and words). It is only read first: each plan's step count, whether it is new or already there, whether the same file was imported before (a digest of the plans), and the refused rows by line number; Apply writes only when no row is refused. Every new plan comes in as a DRAFT with its own number and audit entry: none is released; a limit with no source, a limit that is not a number, an unknown phase or point, and a step with no criteria are refused (a plan with a refused row is refused whole, so no plan comes in with a step missing); no limit or acceptance value is made up, and the letters A, B and C are not read as phases. A plan with the same title that exists is left as it is, the import never edits it, and with nothing to write no audit entry is made.Not yet: Not built (2026-10-29): importing the class-to-sheet matrix and the punch list of a previous system; CSV (Excel only); a plan whose source reference is empty comes in as a draft and its release is refused until the reference is written. It has not been tried on a customer's own library. | Common In enterprise suites | Partly in the app |
| The owner and a third party sign their own points on their own account, and the doer is not the verifier (WBS 6.3, 6.4)A person of the owner or of the new 'third party' party signs, on the Points for me to sign page, the witness, hold and review points of their own party on planned inspections with their own account (or takes the signature back): it is written under the name of the account and the account stays on the record. A person cannot sign for another party or for the contractor, a subcontractor or a vendor signs no point, and a party never writes its own 'did not come' (the contractor writes that on a notice). They acknowledge the notices sent to them, and the owner's person verifies the punch items the contractor marked done. A third party sees no document of the register. The completion scheme has two switches, both off until the customer decides: points of the owner and the third party are signed only by their own people (the contractor's side cannot record them under a typed name, only the notice-based no-show), and the person who did the work does not verify it (whoever recorded the results or finished an inspection does not sign it, whoever marked a punch item done does not verify it; who acted is read from the audit trail, so a typed name cannot hide it). A refused call is not written to the audit trail and no AI or agent path signs (partners' tests AT-001 and AT-029).Not yet: Not built (2026-10-30): a vendor's own person filling in a FAT sheet on their own account; the owner's person writing a punch waiver (a waiver stays the administrator's); the switches cannot tell one human's two accounts apart. It has not been tried on a real project. | Common In enterprise suites | In the app |
| Import the class matrix from Excel (WBS 6.3, 6.4)On the Classes and properties tab of the Tags page the project administrator picks a file with one row per class, phase and test plan (number or title; Turkish or English headings). It is read first: the earlier and the new list of each class, the refused rows by line and whether the same file was applied before (a SHA-256 of what was read). A row is refused when the class is not in the profile, the plan does not exist or is retired, its phase is another or empty, or the plan is listed twice for the phase; a class with a refused row is refused whole, and Apply is refused (422) with nothing written while a row is refused. Applied, the check sheet list of each class the file names is replaced with the file's and other classes are left alone, in one transaction with one audit entry holding the list before and after; a class already as the file says writes nothing. The matrix generates no sheet and releases no plan.Not yet: Not built (2026-10-30): CSV (Excel only). It has not been tried on a real project. | Common In enterprise suites | In the app |
| Import the open punch items of a previous system from Excel (WBS 6.3, 6.4)On the Punch page the quality writers pick a file with one item per row: the number the previous system gave it (required: it makes a second reading safe), the description, the category (A, B or C, never guessed), the responsible company and a system or location; optionally the due date, the day raised, who raised it and which company, the tag (it must be in the register), the discipline and the stage found. It is read first: whether each item is new or already there, the refused rows by line and whether the same file was applied before. A row with no category or number, a number twice, a date in the future or an unknown stage or tag is refused, and Apply is refused (422) with nothing written while a row is refused. Applied, each item comes in like one typed by hand: its own number, open, with its previous number kept (a new column with a partial unique index); none is closed, verified or waived. An item whose previous number is on the list is left as it is, so applying the same file twice writes nothing.Not yet: Not built (2026-10-30): the history of closed items (only the open ones come across); CSV; the attachments and photos of the previous system. It has not been tried on a real project. | Common In enterprise suites | In the app |
| Completion: the readiness review, preservation and a test plan draft from a manual (WBS 6.3, 6.4)Certificates (MC, RFC, RFSU, handover or provisional acceptance, as the customer's approved scheme names them) per subsystem or system, issued only when the sheets are done and no punch of the blocking category is open, signed by role on both sides; a library of A, B and C sheets with acceptance criteria and a class-to-sheet matrix that generates the sheets per tag; measured values against criteria with instrument and calibration; commissioning procedures with prerequisites and test records; punch by the stage it was found and the gate to clear it; the system dossier with a manifest and the status, certificate and punch clearance reports; a readiness review of a system (an audit kind that writes nothing to a certificate, with the review steps the customer names and a punch item found at the cross examination); preservation tasks per tag from receipt to handover (off until the project administrator switches it on, no interval shipped, a note of evidence each time); and an AI draft of a test plan from a manufacturer's manual that only suggests, with the manual's own words as the criterion, which a person adds to a draft plan or drops. The rules of Orçin's technical review hold: one shared set of objects (document and revision, tag and equipment, supplier), the work breakdown and the system breakdown kept apart, AI may propose and draft and never invents an acceptance value, signs, or closes a test or a gate, a hold point is never waived, and a refused call is not written to the audit trail.Not yet: Preservation (2026-10-30, still off in every project until the project administrator switches it on): an e-mail to the roles that write the maintenance plan 7 days before a task is due and weekly while it is overdue (its own switch in the notice settings; never sent for a project with preservation off), the receipt day offered from the receiving report of the tag (the earliest report that stands; a person confirms it or types another day), and an Excel file of the tasks and every record. Not built (2026-10-30): taking a limit with its source from the manual (a person writes the limit); the partners' approval of the AI draft (it shares the switch of the IOM reader and is off by default until then). The partners' acceptance tests T01 to T05 are written and hold as far as the frozen contents of a certificate. It has not been tried on a real project. | Common In enterprise suites | Partly in the app |
| Tag renumbering history; IEC 81346 ★A tag can be renumbered with a reason: the old number stays on its history with who and when, keeps finding the tag in searches, Excel files and plant data, and is never given to another tag; documents, equipment, site records and plant points follow the tag. IEC 81346 designations (=function, -product, +location) are an option for the tag number format and the handover check tests them. Tags are found and filtered by the parts of a designation (a name matches what lies under it, A* by prefix), free numbers are converted to designations by rules the project writes (a pattern, templates for the three aspects and tables of system and area codes), previewed first and renumbered in one transaction, and many tags are renumbered from a file of current number, new number and reason, each row checked in order. | Not found elsewhere | In the app |
| Two-way sync between tag register and maintenance system ★Keeps the tag register and the maintenance system (EAM) in sync both ways, through an adapter for IBM Maximo (REST and OSLC) and one for SAP PM (OData). Tags, equipment and the documents that describe them go out (by default the handed-over tags); the EAM's own id and status come back and show on the tag's card. A field is sent only when we changed it since the two last agreed; when the EAM changed it, or both did, the difference is listed for a person, who keeps ours (sent to the EAM), takes the EAM's (written into the register with an audit entry) or leaves it with a reason. A sync is previewed and applied with the preview's fingerprint, and only the register and the EAM are read and written: nothing reaches a plant system.Not yet: Tried against a fake Maximo and a fake SAP server only: the paths and field names are our reading of the two systems and a first run belongs with the owner's EAM team on a test system. SAP document info records (DMS) are not built; documents go only as Maximo document links. | Not found elsewhere | Partly in the app |
| As-built record and handover to the employer ★Keeps the as-built deliverables a contract expects, made from the project's template (to start with the KGM list as research report 35 reads it: original projects, dgn, dwg and ncz CAD files, PDF at 200 dpi, GeoTIFF for coordinated sheets, the design program files, ITRF96), each with its delivery, the acceptance of the owner's person and the place it is kept. Provisional acceptance cannot be recorded while a required deliverable is not accepted; a reason lets it go ahead and is kept with the codes that were open. A GIS-ready package in our own layout (until the owner's specification arrives) holds the documents at a final stage with the files of their current revision, one folder each, a manifest with the size and SHA-256 of every file, the deliverables with their coordinate systems, the tags and the findings of its check as one zip. Each delivery also carries files through the scanned upload (SHA-256 and size kept): the type is read from the first bytes (PDF, TIFF and GeoTIFF, DWG with its version, DGN V7 and V8, PNG, JPEG, ZIP), the resolution of a PDF (the embedded picture against the page size) and of a TIFF, and the EPSG code of a GeoTIFF from the file itself, and the findings (wrong type, resolution below the template, an EPSG code outside the template's system list, a stated system that differs from the one read, a file not readable) are shown to the person who accepts and recorded with the acceptance without blocking it. A delivery points at register documents (their stage and revision are read, never written, and one not at a final or as-built stage is a finding), and the drawings of an accepted delivery are linked to tags of the asset register.Not yet: The package layout of the ISKI specification is not built (the specification was not obtained). The coordinate system of a DWG or DGN is not read from the file (what the delivery states stands), the resolution of a PDF assumes the picture spans the page, and the starting list of EPSG codes for ITRF96 was written from memory of the registry and is to be checked. | Not found elsewhere | Partly in the app |
| Warranties and the defects notification period, with defects and the final acceptance gateRecords warranties for a tag, a system, a supplier, a subcontract or anything else: a tag and a system are checked against the tag register and the document against the document register; the length starts at provisional acceptance (the day on the Close-out page), delivery, commissioning or a day typed and runs for a number of months; the end is worked out each time and not stored; the state is not started, running, ending soon (within 90 days) or expired, and a warranty is voided with a reason and stays on record. The defects notification period of each contract (main contract, subcontract, supply) holds its start, its months, the contract's response time in days and the clause. A defect is reported by someone on a day and has to fall inside its period or its warranty (a defect before the start belongs to the punch list); the contract's response time as it stood on the day is written on the defect and gives the day to answer by, with the days late once it passes; it is answered, remedied, closed (the owner's acceptance) or rejected with a reason and reopened with a reason, all in the audit trail. Final acceptance cannot be recorded while a defect is open or waiting for acceptance: a reason lets it go ahead, and the reason and the defect numbers stay on the record. Ninety, 30 and 7 days before a warranty or a period ends, the people who keep the warranties get one e-mail for each mark, and a length that is extended starts its marks again. The periods are the contract's; the page counts the days and says to check them against the contract.Not yet: Not built (2026-10-26): an e-mail reminder for a defect whose response is late (it shows on the page only), files and photographs on a defect, extending the notification period for a defect (FIDIC 11.3), sending a defect notice to the supplier, and warranties on the tag panel and in the handover report. Competitors were not surveyed for this feature, and it has not been tried on a real project. | Rare | In the app |
| O&M training sessions per system, with attendance and results, as part of the handover dossierA session has a subject, a system (in the spelling of the tag register), an audience, a trainer and company, a planned day, a length in half hours, a place and the numbers of the documents used (checked against the register). When it is held the day (not ahead of today) and the attendees are recorded: name, company, role, whether they signed the attendance sheet and the result (attended, passed, did not pass); the same person cannot be listed twice in a session. A held session is a record: it does not change, it is reopened with a reason to be corrected (the list of attendees is kept) and that goes to the audit trail; a planned session is cancelled with a reason. The Handover dossier tab gives, for each system of the tag register and of the sessions, the sessions held, the people trained (once by name and company, the best result across sessions and a signature if they signed even once), the signatures, those who passed, the hours, the documents used and the last session, and shows a system with no training plainly; it downloads as a three-sheet Excel file (systems, sessions, attendance). The training of the project's own team (role paths and the training record) is a separate row. The risk readers read it and the quality roles write it; outside parties do not see it. Not yet: making a system with no training a gate in the system report of the Handover page, keeping the signed sheet as a file on the session, producing an attendance certificate, training templates by tag class and one person's history across systems; not tried on a real project. | Rare | In the app |
Plant data (OT) · 4
| Read-only plant data connection and historianReads values from plant systems and historians without writing back: OPC UA, Modbus TCP (read functions only), MQTT with Sparkplug B payloads (subscribes only, publishes nothing) and historian files; asks an OPC UA server with history or a PI Web API for the values of a range (at most 31 days) and keeps them thinned, with a trend beyond the day on the point's panel. Each reader was tried against a stand-in server of its protocol that records what it receives, not against a real PLC, broker or PI system.Not yet: IEC 60870-5-104, DNP3 and BACnet readers, other historians' interfaces (AVEVA, Canary), the customer's own certificate authority for mqtts and an OPC UA subscription are not built: each needs a device or a server to be built against. None of the readers has run against a real plant. | Rare In enterprise suites | Partly in the app |
| Engineering versus plant tag mismatch report ★Compares the tag register with a SCADA or historian tag export, read only: tags only in engineering, tags only in SCADA, and differences in description, unit, range and alarm limits (HH, H, L, LL), matched by number, former number and the project's mapping rules. The list can also come from a live browse of the plant's OPC UA server (variables with their unit, range and the alarm limits it states). The report downloads as Excel and a SCADA tag can become a draft tag for review. Nothing is written to the plant. Not yet tried against a real control system. | Not found elsewhere | In the app |
| Live value on the equipment card; fixed price per site ★Shows the live plant value on each equipment card at a fixed price per site. | Rare In enterprise suites | In the app |
| Work order from alarm with datasheet and FMEA attached ★An alarm on a plant point mapped to a tag (a good reading reaching the alarm limit engineering gives the tag, or one typed for the point) opens a work-order draft that names the tag's datasheet and FMEA and says which is missing; a person issues it in Lintara or in the owner's EAM (Maximo or SAP PM, through the EAM connection) and the EAM's number is kept. Nothing is sent to the control system. The EAM calls were tried only against fake servers. | Not found elsewhere | In the app |
AI · 19
| Reading handwritten comments from a scanOff by default: a project administrator turns it on in the project settings, where a plain notice names the outside AI service (Anthropic to begin with), says that every page of the scan is sent to it with the document number, title and revision and nothing else, and that it is outside Turkey. A reviewer prints the drawing, writes comments on it by hand, scans or photographs it (PDF, JPG, PNG, or a phone's HEIC, which the server turns into a JPEG) and attaches it as their commented copy. "Read handwritten comments" then sends it page by page and gets back proposed comments: the text as read, the page, an approximate box, a confidence, and whether it looked like a comment, a revision cloud, a strike-through or a tick (structured JSON output, validated). When the revision has a clean PDF, each scan page is lined up with it (the tilt is taken out and the sheet border is stretched over the clean one; a photo taken at an angle is not corrected, and a page whose border does not have the same shape is not placed), so an accepted comment is also placed on the clean PDF. A confirm screen shows the scan on one side and the proposals on the other, each with its crop of the scan: accept, edit or drop; low-confidence ones are marked. An accepted proposal becomes a comment of the step with the source "handwritten scan" and a link to its crop; nothing reaches the comment sheet without a person. Every call is audited (who, which file, which model, how many pages, how many results). The scan stays attached as the commented copy either way, and while the setting is off, or the server has no key, nothing is sent. Honest limits: messy handwriting, faint scans and stamps over text are read badly, and accuracy has not been measured on real reviewed drawings. Not covered: handwriting on Word or Excel copies, perspective correction, a monthly cap, other providers. | Not found elsewhere | In the app |
| Cited question answering over project records ★For a question the exact answers cannot take, the assistant asks an outside AI service (off by default: a project administrator and a company administrator both allow it). The model can only call five tools that read, limited to what the asking person may see (project membership, drafts only for their author) and to one project, and it must end with an answer that cites records. Every quote is checked in code against the stored text of the record: what is not there is dropped, and with nothing left the answer is "not in the record" with the nearest records it looked at. Numbers of documents, RFIs, letters and transmittals in the text are checked against the database, and an unknown one is not linked and is marked. Counts, totals and rankings are never done by the model. Card, ID and IBAN numbers and e-mail addresses are hidden before anything is sent. Every call is logged (who, project, model, tokens, cost, time, error; the question only if the company turns that on) and counts against the company's monthly limit (USD 20 by default), after which the AI stops with a clear message while the exact answers go on. Search is PostgreSQL full text with Turkish and English stemming plus trigrams; vector search is not used yet. A 30-question evaluation set reports the found-rate and the wrong-citation rate apart. Answers can be wrong: every answer shows its sources, and the assistant never sends, approves or changes anything. Turkish and English; no Arabic yet, and accuracy on a customer's own documents is not measured. | Common In enterprise suites | In the app |
| Correspondence classification and auto-linking (AI) ★Built: for an incoming letter or e-mail the "Suggested" panel proposes its type, discipline, the documents, RFIs, changes and claims it is about and whether it asks for a reply and by when, each with the words it was read from; a person accepts all, accepts one by one, edits or dismisses, and only then is a record changed (the audit trail says the link came from an AI suggestion). Off by default: a project administrator turns it on in the project settings, after the company has recorded its acknowledgement of the transfer abroad; a second switch, also off, has the server prepare the suggestion when a mail arrives, and it applies nothing either. The outside AI service is sent the subject, the text with the names of people masked, the sender's organisation, the date and up to 200 record numbers the code chose, and the first pages of an attachment only if a person asks. The code drops every record that is not in that list, every quotation that is not in the letter and every code the dictionary does not hold, and adds "within N days" to the date of the letter itself; nothing in a letter can name a status or an action. The model is Haiku 5.5 at low effort, set per use in the server environment. The pilot page counts letters suggested for and proposals accepted as proposed, edited or dismissed. Classifying an incoming mail as a transmittal stays the Inbox's rule in code. The service can propose a wrong link and its accuracy has not been measured. | Rare | In the app |
| Comment merging (AI) and CRS draft ★Merging, built: when several reviewers write the same thing, the consolidator asks the AI for a proposal and a person decides each group. Off by default: a project administrator turns it on in the project settings (and only after the company has recorded its acknowledgement of the transfer abroad), where a plain notice names the outside AI service, says that the comment texts of the round and the document number, title and revision are sent to it, that the reviewers' names are masked as Reviewer 1, 2 and the real names stay in the system, and which service and region the company chose (Anthropic's own service unless the company chose another). The service proposes groups of comments that say the same thing, a merged wording, the discipline and why; the code checks that every comment exists, belongs to the round and is in one group at most, and works out the type, pages and discipline itself, so nothing in a comment or a reply can name a status or a code. A person accepts a group (editing the wording or taking comments out of it) or drops it; an accepted group becomes one comment tied to its sources, the sources say they were merged into it, the author answers once and the answer reaches every source, and it can be undone until the author answers. The CRS Excel has a Merged column, the audit trail says who accepted which group, and the pilot page counts comments in, merged comments out and groups accepted as proposed, edited or dropped. The model is Sonnet 5.5 at medium effort, set per use in the server environment. The service can propose a wrong group and its accuracy has not been measured. After a merge a second card offers a reply draft for each merged comment (it lists what the comment asks for and writes an acknowledgement, says nothing was done, accepted or rejected, and its outcome is "Research": the author picks the disposition), evidence in the text of the new revision (code picks the pages that share words with the comment, the service shows a quote, code looks the quote up in that page and drops it if it is not there; finding none does not mean the revision lacks it), and a code-only check that flags comments answered accepted with a revision named whose page text did not change in that revision. A person decides each proposal and none changes a comment, its answer or its status; the decisions go to the accuracy card. | Rare In enterprise suites | In the app |
| Contract notice and time-bar calendar ★Reads the contract and its particular conditions for their own notice, reply and time bar periods: the text layer in code, pages without one as images to the outside AI service, a run of clauses at a time, with the cost shown before the reading starts. Each proposed period has its clause, the contract's own words quoted, what starts it, the length (days, weeks or months, calendar or working), who must act, whether missing it loses the right and the kind of record it applies to; code drops a proposal whose quote is not in the clause and counts the days itself. A person accepts, edits or drops each one; accepted periods go into the register with their source clause, which says for each period whether it came from the profile or the contract, and a period takes the place of a default (notice days of new claims, review period by document type, a payment period where there is no main contract register) only when the project administrator says so. Periods counted from a date of the contract appear in the calendar as fixed dates, those that start with an event attach to the open records, and an e-mail goes 7, 3 and 1 days before they run out. An e-mail is not a valid notice unless the contract says so: Lintara counts the days and gives no legal advice. Off by default on every project and behind the company's acknowledgement. | Rare | In the app |
| Progress report narrative, schedule check, late review remindersBuilt: a Monthly report page shows the figures of each section of the monthly progress report, made in code and with no AI: progress, earned value (PV, EV, AC, SPI, CPI), the schedule's SPI(t) and DCMA result with the activities that entered or left the critical path since the last schedule, and the month's reviews (answered, on time, late, waiting). Late reviews are also mailed to reviewers daily. The AI part is optional and off by default: a project administrator turns it on in the project settings, after the company has recorded its acknowledgement of the transfer abroad, and the outside AI service then drafts a few sentences for each section from those figures only. Code drops a draft whose text carries a number that is not among that section's figures, the model gives no causes or forecasts, and a person edits, accepts into the report or drops each draft; the accepted text joins the Excel report as a Narrative sheet beside the figures it was written from. On the schedule's Health tab the same switch lets a planner ask for a plain explanation and up to three proposed notes for each failed DCMA-14 point: code finds the failing activities and the model can name them only by their code, a text with a number that is not among the point's figures or the code of another activity is dropped, and a note a planner accepts changes nothing in the schedule. The model is Sonnet 5.5 at medium effort, set per use in the server environment. The counts of drafts accepted as they stood, edited and dropped show on the card in Settings; the accuracy of the wording has not been measured. | Rare In enterprise suites | In the app |
| Deliverable check against specification ★Built: on the review page the reviewer whose turn it is, or document control, picks a specification of the register whose text has been read; code cuts its clauses at their numbers, up to 25 are ticked and a page range of the supplier's document is given (80 pages at most). Only the text of those clauses and pages and the number, title and revision of both documents go to the outside AI service. For each requirement the service gives the specification quote, the document quote with its page and a reading of complies, deviates or not found; code looks both quotes up in the texts that were sent (spaces, line breaks, quotes and dashes do not count) and drops a row whose quote is not there, does the counting itself and writes the comment from the two quotes. The rows show side by side; the reviewer confirms, changes the reading, edits the comment or drops each row, and a confirmed deviation (mandatory) or unanswered requirement (question) becomes a comment of their review step. Off by default on a project, behind the company's acknowledgement and use switch; claude-sonnet-5-5 at high effort; the counts of accepted, edited and dropped rows are kept and are not a claim of accuracy. Not yet tried with a real AI key. Missing: reading a page with no text from its picture (only pages the OCR read), comparing revisions of the specification, a deliverable of several files, a specification in Arabic script. | Rare In enterprise suites | In the app |
| Variation and claim evidence file ★Built: on a claim's panel and under the Variations tab, code gathers the letters, e-mails, RFIs, daily reports, photo captions and schedule changes that the claim or variation names or that are dated near its event and share its words (up to 60, with the names of people, telephone numbers, addresses and card or identity numbers masked). Listing them and building the file by hand work without AI: a person ties each record to one of four points (the event, the notice, an instruction or approval, the effect on time or cost). If a project administrator turns the AI on (off by default, behind the company's acknowledgement and use switch), the outside AI service proposes which record shows which point, with the words that show it; code drops a row for a record that is not in the set, a point that is not one of the four and words that are not in the record's text, and a person accepts, moves or drops each proposal. Code works out the chronology, the days from the event, the gaps and the points no record shows. The file leaves in the existing hashed evidence pack: the accepted e-mails as received, the other records as they are then, chronology.csv and a manifest with the SHA-256 of every file; the pack says a person built the file and that it is not legal advice. claude-sonnet-5-5 at medium effort; the counts of accepted, edited and dropped proposals are kept and are not a claim of accuracy. Not yet tried with a real AI key. Missing: the text of mail attachments and documents as candidates, photos of NCRs, punch items and receiving reports, the photo files themselves. | Rare | In the app |
| Progress payment check ★Built: a Check tab on every payment application compares it, in code and with no AI, with the progress records of its cut-off day: what each line claims against what the rules of credit earn, the arithmetic of the lines and the totals, the cumulative against the previous application, the retention and advance recovery against their rates and the limits of the main contract, the price adjustment worked out again from its formula and indices, the taxes and deductions worked out again from the tax table, and progress that no line covers. Each finding has its kind, line, the two amounts, the difference and a severity (high, medium, low); an issued application is read against the register as it is today, so a record entered late shows the difference without changing the application. A person marks a finding reviewed with a note, and issuing with a high finding nobody reviewed asks for a reason that goes to the audit trail; the findings download as Excel. A measured quantity is typed on the application, not read from a record, so the check notes it and does not compare it. The AI part is optional and off by default: a project administrator turns it on in the project settings, after the company has recorded its acknowledgement of the transfer abroad, and the outside AI service then writes a short explanation of each finding and a summary. It is sent the findings (every amount made in code) and the line descriptions, never the names of people; a text with a number that is not in the findings is dropped by the code, and an explanation changes no record. The model is Haiku 5.5 at low effort, set per use in the server environment. The accuracy of the explanation has not been measured. | Not found elsewhere | In the app |
| Tag attributes from datasheets; daily report from voice note and photoBuilt (tag attributes from datasheets): in the tag panel document control picks a datasheet (the tag's linked documents first; its text must have been read) and up to 12 pages. Only the text of those pages, the tag number and class, the class's list of attributes and the document's number, title and revision go to the outside AI service, which looks only for the class's attributes and gives each value with its unit, page and the datasheet's words. Code looks the words up on that page and checks that the value is in them (sign included), that a number is a number and that the unit is the class's or one it can convert; it converts the unit itself (pressure, length, mass, power, voltage, current, temperature, volume and flow; gauge and absolute pressure are never mixed) and drops a value that fails a check. A number property in the class library may carry a lower and upper limit; a value outside it is flagged and is kept only when the person says it is right. The person accepts, edits or drops each value; an accepted value is written into the tag's property in the same change, and the audit trail keeps the old value, the datasheet, the revision and the page. Off by default on a project, behind the company's acknowledgement and use switch; claude-haiku-5-5 at low effort; the counts of accepted, edited and dropped values are kept and are not a claim of accuracy. Not yet tried with a real AI key. Missing (datasheet): picking the right column of a datasheet that holds several tags is left to the person, who compares the quote with the page; a value in a unit outside the conversion table is dropped. Built (daily report from a voice note and photos): on a draft daily report the foreman dictates a note (the browser turns the voice into text on the device itself; a browser that cannot do that on the device gets no microphone button and the note is typed, and no sound is sent or kept) and attaches photos with a typed caption each (the photo files are not uploaded). Only the text, the captions and the date of the report go to the outside AI service, which proposes lines for the work done, the crews, the equipment and the issues, each with the words it comes from. Code looks the words up in the note, checks that every number is in them (digits or words), compares crews and equipment with the project's lists (the subcontractor register and earlier reports) and asks for a "this is new" tick on a name that is on none; the weather, who is responsible for a delay and whether a machine is owned or rented are never taken from the service. The foreman accepts, changes or drops each line, and an accepted line is written into the draft report in the same change with an audit entry. Off by default, behind the company's acknowledgement and use switch; claude-haiku-5-5 at low effort; the counts are kept and are not a claim of accuracy. Not yet tried with a real AI key. Missing (daily report): the service reads the captions only, not the pictures; speech to text on the device needs a browser that supports it; the weather is never filled in. | Rare In enterprise suites | In the app |
| Archive intake (AI): number, revision and title proposed from scans ★Upload old scans and PDFs (PDF, TIFF, JPEG, PNG or a zip of them, up to 500 files a batch) and the title block on the first page of each is read into a proposed register row: number, revision, title, discipline, type, date and sheet, each with its confidence and the box it was read from. A PDF with a text layer is read in code and nothing is sent; for any other file only an image of the title block area (corner, strip or the whole first page, chosen per batch) goes to the outside AI service, never the whole file and nothing about the project. Every field is checked in code against the number masks and dictionary codes, the revision scheme and the register and batch for duplicates, and the row is green, amber or red. A person accepts, edits or drops each row, accepts all green rows at once, or has amber and red rows read again by a careful reader; an accepted row makes the document or a new revision with its file attached through the register's own rules, marked as registered from archive intake. Nothing enters the register until someone accepts it. Off by default, behind the company's acknowledgement. The pilot measures page counts files read, fields accepted unchanged and edited, rows read again and dropped in SQL, with an Excel file, and prints no accuracy figure. No measured accuracy on real archives yet. | Rare | In the app |
| Tag reading from old archives and P&IDs ★Reads tags from old archive drawings and P&IDs and queues each result for a person to approve. Title block and revision intake is built, and so is tag reading and linking for files attached to a register document: from the text layer or OCR without AI, and by a vision model for pages a person sends. Reading the symbols and connections of a P&ID and DEXPI are described in the entry "DEXPI from P&ID; maintenance plan from operating manuals". Missing: a trial on real scanned archives with a real AI key; so far only a stand-in service has been used and accuracy has not been measured. | Not found elsewhere | In the app |
| Published accuracy on the customer's own documents ★Measures answer accuracy in each pilot on about 400 questions with evidence pages and publishes confidence ranges by language and document type against agreed pass gates. The card in project Settings is built: for each AI use it counts proposals, accepted as they stood, accepted after a change and dropped, the number of decisions and the share taken as proposed with its 95 percent range, all in SQL from the project's records, and says that it counts decisions and is not a measure of accuracy.Not yet: The accuracy card of decision counts exists; missing: the evaluation on about 400 questions with evidence pages on the customer's own documents, ranges by language and document type and the pass gates, which need the customer's documents and reference answers a person prepares; no accuracy figure is stated until then. | Not found elsewhere | Partly in the app |
| Model gateway: provider, region and model choice per customer ★Sets provider, region, model version, retention, monthly cap and language routing per customer; models are pinned and changed only after passing the saved evaluation set. A company administrator chooses, per AI use, Anthropic direct, Claude on Amazon Bedrock or Google Vertex AI in an EU or Gulf region from a list, or a model server of the customer's own; keys and addresses belong to the server's operator.Not yet: A model and effort per AI use (env vars), a monthly cap per company, a call log with cost, and the company's choice of service, region and model per use in the company settings (Anthropic direct, Amazon Bedrock and Google Vertex AI in EU and Gulf regions, a customer-hosted server) exist, each service as an adapter tested against a stand-in transport; no AI use can be switched on, and no call is made, until the company has recorded the acknowledgement of the transfer abroad. Also exist, each tested against a stand-in: routing by the language of the text sent (Turkish, English, Arabic, Russian, other; the language is found in code, the call log says which route won; off unless set), the company's recorded statement per service of whether it may keep prompts (shown beside each route and on the security pack's data flow; "may keep" warns and does not block), a saved evaluation set of up to 200 rows built from the company's own accepted results that pins the model (a change of model for a pinned use is refused until a run of the set on the new model, counted against the cap and started with a fresh second factor, passes the company's threshold; so far the set can be built for linking a letter or mail), and Vertex sign-in by service account with token renewal. Missing: the first live call to each real service and its model ids (the operator), a Turkish region, and evaluation sets for the other uses. | Not found elsewhere | Partly in the app |
| Document text treated as untrusted input ★Blocks side effects in question answering, strips links and images from answers, enforces permissions before text reaches the model and keeps a tamper-proof access log.Not yet: Read-only tools with strict inputs, a permission filter before text reaches the model, records passed in a field marked as data, links, images and HTML taken out of answers and quotes in code, scan proposals limited to four fields and a person's confirmation, suspected instructions noted without their words, masking and citation checks, an append-only call log (service, region, model, digests of the prompt and the request, size, cost, the records used; the application's database role cannot change or delete a row), a hash chain over its rows (each new row carries the SHA-256 of the company's previous row and of its own content, a company administrator can check the chain and is told where it first breaks, rows written before the chain are outside it) with a retention period the company sets (12 to 120 months; off until set; the weekly retention job removes only from the start of the chain, with the role that owns the table, and records the new start in the audit trail) and a check for white, tiny and off-page text in PDFs (a page with enough of it is not sent, and it stays out of the indexed text) exist; missing: an outside copy of the latest digest (whoever owns the table could rewrite the whole chain or cut its tail), white text laid over other writing is not caught, and hidden text in Word and Excel files is looked for only in the PDF LibreOffice makes. | Not found elsewhere | Partly in the app |
| Drawing search by title block, tag and OCR text ★The words of a drawing, from its text layer or the OCR of a scanned page, are kept with their place on the sheet; code finds the tags among them against the register and the project's numbering and proposes each with its page and box, and a person accepts, corrects or rejects it (an accepted find links the tag to the document; nothing is made or linked by code), a new revision is compared with the one before, and the file search frames the words and tags on the sheet. Pages with no text layer, very few words or a poor OCR reading are offered to a person, who sees the page count and a cost estimate, ticks pages off and sends the rest to an outside AI service in overlapping tiles (only the picture, the document number, title and revision and the project's tag patterns go); what it reads is cleaned in code, joins the same search marked as AI, never replaces a text layer, and its tags go through the same checks and the same review. Off by default, with the project administrator's and the company's switches and the company's monthly limit; reading on upload is a second, separate switch. The pilot page counts the finds of the text layer, OCR and AI side by side and does not claim that the AI reads better than OCR. Not yet: a page image sent when a question is asked, drawing question answering, a test on real scanned P&IDs. | Not found elsewhere | In the app |
| AI in Turkey, the Gulf or on the customer's server ★Runs the AI features in Turkish or Gulf regions, or on the customer's own server. Built: a company picks an EU or Gulf region on Amazon Bedrock or Google Vertex AI, or a model server on the customer's own premises (chat completions protocol; pictures only; nothing goes to another service and it needs no Anthropic key).Not yet: Region choice on Bedrock and Vertex and the customer-hosted server exist as adapters tested against a stand-in transport; missing: the first live call to a real region and a real customer server (the operator), a Turkish region (neither service lists one; a model hosted in Turkey goes through the customer-hosted server), and any measure of how well an open-weight model reads Turkish and English or follows instructions. | Not found elsewhere | Partly in the app |
| DEXPI from P&ID; maintenance plan from operating manuals ★Built (symbols of a P&ID and DEXPI): on a drawing document control picks a page. The outside AI service (off by default on a project, behind the company's acknowledgement and use switch) is sent the picture of the page, the tag-like words that code already read from it with their places, and the document's number, title and revision and the project's tag patterns; it proposes the equipment, instruments and valves with their tags and boxes, and the lines that join them as connections. Code checks every tag against the words read from the page and against the tag register and drops a symbol that is in neither, writes the evidence beside each symbol (on the page and at the symbol, on the page but elsewhere, a register tag, a register tag one character away), checks that both ends of a connection are symbols that were kept and that a line number it names is on the page, and cleans everything the service writes; the reply has no field that could name a status or an action. A person accepts, corrects or rejects each symbol and each connection (a connection needs both ends accepted); accepting a symbol whose tag is in the register links the tag to the document in the same change, with an audit entry; no tag or link is made by code. Accepted symbols and the accepted connections between them download as a DEXPI 1.3 plant model for the page, and a DEXPI file comes in as proposals for a page that are checked and decided the same way, without AI. claude-sonnet-5-5 at medium effort; the counts are kept and are not a claim of accuracy. Built (maintenance tasks from an IOM manual): on the Templates tab of the Maintenance page the project administrator picks a tag class and a manual (up to 20 pages) and sees the estimated cost before anything is sent; the service is sent only the text of those pages and the class, and proposes tasks with the interval and unit as the manual prints them, the trade, the page, the manual's words and the spare parts it names. Code looks each quote up on its page, checks that the interval's number and a word of its unit are in the quote, turns the interval into days or running hours itself, checks every spare part against its quote (a quantity the quote does not give is taken as 1 and marked) and every trade against the plan's trades. The person accepts, edits or drops each task; an accepted task is added to the class's templates in one change with an audit entry that names the manual, its revision, the page and the words, and the plan changes only when it is generated again. claude-haiku-5-5 at medium effort; off by default. Missing: the DEXPI file passes the project's own structural check, but the official DEXPI schema file is not in the repository and has not been run, and DEXPI's own verification tools and another tool's files have not been tried on a real P&ID; only equipment, instrumentation functions, valves and connections are written (no nozzles, piping classes and line attributes, instrument loops or signal lines); neither use has been tried with a real AI key or on real drawings and manuals, so reading quality is unmeasured; tables and pictures in a manual are not read. | Rare | In the app |
| Agents that carry out approved actions; alarm explanationBuilt (agents that act only on approval): a person who keeps the action log or the register writes Linto a task, such as chasing the late reviews or drafting the transmittal for named documents. The outside AI service (off by default on a project, behind the company's acknowledgement and use switch) is sent the task, the late review steps, the open actions, the documents the task names by number and the project's stage codes, and proposes steps from a fixed list: add an action to the action log, mark an action done, issue an outgoing transmittal. The list has no delete and nothing that writes to a plant. Code checks every step against the records (a document, review or action that does not exist, a date in the past, a stage or purpose the project does not have: dropped), writes the exact effect of each step in both languages itself and ignores any field the service adds. The person approves or refuses each step on its own; an approved step runs in one transaction through the code the record's own page uses, with that person's own role (a transmittal only for an administrator or document control), and the audit trail records "approved agent step"; if the existing code refuses it nothing changes and the step stays "could not be done" with the reason. claude-sonnet-5-5 at medium effort; steps proposed, approved, refused and not done are counted on the pilot page and are not a claim of accuracy. Built (alarm explanation): an alarm export (CSV: tag, time, text, priority, state) is kept against the points of the plant data on the Alarms tab, the same file twice adding nothing. For an alarm on a point mapped to a tag, the person who keeps the plant data picks the tag's datasheet and FMEA (documents whose text was read), and the service proposes likely causes. Code ties every cause to a quote found on a page of the datasheet or the FMEA, or to the words of a numbered fact it worked out itself from the point's recent values (first, last, smallest, largest and mean value of the two hours before the alarm, the change and its hourly rate, the largest step, the half hour after, the samples of bad quality), and drops a cause with no support or with a number that is not in the quotes it rests on. The explanation is shown beside the alarm, can be marked useful or not, changes nothing, writes nothing to a plant and gives nobody work. claude-haiku-5-5 at low effort.Not yet: Not built: the agent's other actions (sending an e-mail or a reminder, opening an RFI, a review comment or another record; each would be added as an approved action of its own), live alarms and events (OPC UA Alarms and Conditions and a historian's alarm query need access on the plant side; today the alarm log comes in as a file), a structured FMEA table (today the FMEA is a document whose text was read), and any test of the plans and explanations with a real AI key on real records (only a stand-in service was used, so accuracy has not been measured). Writing to a plant is not built and no agent action does it; it waits for the certified-supplier path under Turkish Law 7545. | Rare In enterprise suites | In the app |
Platform · 26
| Multiple projects, roles, permissions and sign-in; two-step verificationSupports many projects with roles and permissions, invitations, two-step verification (TOTP, passkeys, recovery codes), session limits and a session list. | Expected by buyers In enterprise suites | In the app |
| REST APIExposes the system through a REST API. | Expected by buyers In enterprise suites | In the app |
| Native mobile app (iOS, Android)Provides mobile apps, first as a web app and later as native apps.Not yet: The web app installs on a phone as a PWA for site entry, and the source of a native iOS and Android shell is written (app/native): a Capacitor shell that opens the web app, a first page that asks for the install's address and checks it answers like a Lintara, a configuration made by rules that refuses a plain http address before anything is built, local build scripts with no CI; inside the shell the phone registers for push notifications after sign-in, a tap opens only a page of this install, and the server keeps the devices and sends through Firebase Cloud Messaging with a record number, a project code or a count and never a title or a name; all tried against a fake Firebase and a fake shell. Missing: the shell has never been built into an app or run on a phone or emulator, and store listing needs the Apple Developer Program and Google Play Console accounts, a Firebase project with the Apple push key, and a decision on the bundle id: the product opens none of them. | Expected by buyers In enterprise suites | Partly in the app |
| Free external participants; employer, EPC and supplier in one project ★Lets employer, EPC contractor and suppliers work in one project, with outside participants at no charge and never a paid seat. A person from outside is given a party (owner, subcontractor or vendor) and a company; every route the server offers them is on a short list and each filters to their own items, so a route added later stays closed to them until it is listed. The owner sees only the documents issued to it and, when the project turns it on (off by default, import stays the default way), does its review in the app: comments and markups on the file, then a return with one of the project's own owner codes, which records the incoming transmittal the way an import does and applies the code. Subcontractors and vendors send documents and answer comments. Everything is audited with the party and shows to document control marked as coming from outside; a person with no party can only read. The owner can return up to 50 documents in one return (one incoming transmittal with a line each, in one step: if any review is not theirs, none goes), and outside people get at most one e-mail a day when something waits for them (documents to review, comments to answer, a vendor's documents due, decisions on what they sent), only when the list changed or a week passed, with a one-click stop, plus a short push to their registered phones. Missing: an assistant for outside people, and the person switching the e-mail back on from their own page (a project administrator removes the stop for now). | Common In enterprise suites | In the app |
| Regional hosting (Turkey) ★Hosts customer data in Turkey.Not yet: The region is a setting: a company administrator records the region (Turkey, the EU, Saudi Arabia, the Emirates, another place) and the contract's requirement for the data's place, it is compared with the server's own LINTARA_DATA_REGION (it agrees, it differs, or the server says nothing) and nothing is moved; the install guide covers a Turkish data centre (docs/cloud.md section 4); the security pack and the processing agreement draft carry the region; nothing is bought. Missing: an install at a real Turkish provider, and the vendor's own hosting decision (H1) is not made. | Common In enterprise suites | Partly in the app |
| Installation on the customer's server ★Installs the system on the customer's own server.Not yet: A Docker Compose package exists: the web app over HTTPS, the API, PostgreSQL 16 and a scheduler that runs the encrypted nightly backup and the weekly restore test, brought up by one docker compose up with the first account made from a setup link, a written restore drill, versioned images, an upgrade the customer controls with a rollback by backup, nothing sent out (no telemetry, no update calls, and the page typefaces come from the install itself, so the visitor's browser makes no request to Google Fonts), one example settings file made from the application's own list, and CI that builds the images and runs the stack's health check; missing: a first install on a real machine with the restore drill (the drill is scripted for a throwaway machine, deploy/compose/drill.sh and docs/drill.md, and has not been run on one; no image has been built and run by a person yet). | Rare In enterprise suites | Partly in the app |
| Single deployment package and offline licence; customer cloud ★Ships as one package (Compose, Helm or VM image) with an offline licence file, later deployable in the customer's own cloud with per-tenant data location.Not yet: The Compose package and the offline licence file exist: a file signed with the vendor's Ed25519 key carries the company, the number of projects, a number and the last day, is checked at start and daily with no network, warns in the last 30 days, and makes the install read only when it has ended, is missing or cannot be used (the export of the whole project and the deletion at contract end still work, nothing is deleted); a project beyond the licence's number is refused; a company administrator loads a new file in the app; the vendor has a signing tool and the private key is never in the repository. A company administrator also records a per-tenant data location (region, place, the contract's requirement) and how many months the audit trail stays in the database (13 to 120, never shorter than the server's), which the weekly retention job honours. A Helm chart (web, API with the scheduler, PostgreSQL 16, ClamAV, kept data volumes, a Secret made on the first install and kept across upgrades), a single VM image built with Packer (Ubuntu with Docker and the release's images, a first-start script that turns cloud-init user data into the install's settings) and a guide for a customer's own cloud account in Riyadh and Dubai are written; every value and setting of the chart and the image's first-start script are tested, and helm lint, helm template and packer validate run in CI. Missing: none of the chart, the image or the cloud guide has been installed, booted or tried in a cluster or a cloud account; binding the licence to an installation and revoking it; a first install on a real machine. | Rare In enterprise suites | Partly in the app |
| Two-step sign-in (TOTP, recovery codes); passkeys for administratorsOffers authenticator-app sign-in and recovery codes in every package, passkeys as a second step, and a company rule that requires a passkey of administrators (off by default). | Common | In the app |
| Security pack for customer review ★Supplies CAIQ v4 answers, a data flow diagram, a data processing agreement, a subprocessor list, restore test evidence and a CSA STAR Level 1 entry.Not yet: One list of the subprocessors and the places the data lives exists in the app and on a public trust page (a draft), the result of the nightly backup and the weekly restore test shows on the support page with an e-mail when one fails, and a privacy notice is read at first sign-in, Lintara's own and the company's. A company administrator downloads one zip: CAIQ v4 answers for over 60 CCM controls (Yes, No or NA, who owns each, how it is met and what is left to the customer), made from the product's facts and the install's settings, and answered No where nothing is built (no independent assessment, key rotation, incident plan or penetration test); a data-flow diagram of this install (Mermaid and SVG, only the connections it really has); a draft processing agreement in Turkish and English with open decisions marked for a lawyer; the sub-processor list; the restore-test evidence (every backup and restore line as CSV); the CSA STAR Level 1 steps; and the SHA-256 of every file. CSA's own CAIQ workbook can be filled by control id (marked draft). All of it is a draft and says so. Missing: all 261 CAIQ questions (each control has one answer today), the CSA STAR entry itself (an account at CSA and a person at the vendor), and a lawyer's reading of the agreement and the list. | Not found elsewhere | Partly in the app |
| Free full export in open formats; tested deletion at contract end ★Exports all data in open formats at any time at no charge and deletes it on request at contract end, with the deletion tested.Not yet: Contract-end export (JSON, Excel, CSV, the document files by revision, the Inbox's original messages, manifest with SHA-256) is built from the project settings in the background with a progress bar and a download that expires, and also by API and script; the project is deleted in two steps with the customer's receipt, a second company administrator where there are two, the rows, the files no other record uses and the lines in the audit archives, with a certificate (PDF and JSON) of what stays in the backups and until when; the export about one person, the correction and the pseudonym of a name and address (KVKK art. 11) and the deletion of one file with a reason exist too; after a deletion the digests of the removed files are listed and a weekly job takes them out of the backups' encrypted document-file archives (streamed, the new archive read back whole before it replaces the old one), then reads every archive again and shows the result on the company's page (tested against the real openssl both ways); missing: a run of the export and the deletion on a real server, and a timed run on a very large project (also for the backup job); the database dumps keep a deleted project for up to 56 days and are not rewritten; the certificate still names no date for the file archives, because on a server where the job is not scheduled the files stay. | Rare | Partly in the app |
| Turkish and Arabic (right-to-left) interface ★Offers the interface in Turkish, English, Arabic (right to left) and Russian, chosen per person with a company default.Not yet: The interface is built in Turkish, English, Arabic (right to left, mirrored layout and icons, numbers, revision codes, dates and amounts kept left to right) and Russian; the language is kept with the account and a company administrator sets the company default; a text with no translation shows in English; the reasons the server gives for refusing an action (shared reasons, sign-in and single sign-on, the register, file uploads and reviews, the main contract, payments and cost; a test lists every refusal text still without a translation) and every kind of e-mail notice, including the digest to outside people, come in Arabic or Russian from the same word list; the column headings and sheet names of the document index, CDE register, transmittal, review, RFI and letter lists in Excel can be Arabic or Russian, and the names of the starter rules (upload rules, handover and CFIHOS checks, example rule pack, site mobilisation checks) show in them; and a person can show the Hijri (Umm al-Qura) date beside the Gregorian one, off by default and display only; a project can print it beside the Gregorian date on the transmittal cover, the review sheet, the Gulf payment certificate and the list exports and write Arabic files with Arabic-Indic digits (both off by default and audited; the Gregorian date stays the date of record, a file says once which calendar it adds, codes and numbers are never converted), and a person can show Arabic-Indic digits on Arabic pages while fields take either kind of digit and store Western ones; the labels the account page draws from tables (the notification choices and about 80 more, which the page scanner used to skip and which showed in English; a test now looks for an Arabic and Russian label for every kind of notice), and 385 of Linto's help articles (every article except the HSE ones: the 40 tours and articles of the first-week paths, then the most used ones of the register, drawing, review, site, punch, inspection, payment, transmittal, letter, action, schedule, progress, search, NCR, change and risk pages, then the project settings, company settings, account security, cost, contract and claims articles, then the site, quality, sourcing, plant data, document and CDE, mail, dictionary, classification, CFIHOS, tag, system, handover, close-out, logistics, maintenance, pilot measures, risk, webhook and other module articles; the five site HSE articles of the first-week paths are done, the rest of the HSE module is frozen pending review) are also in Arabic and Russian, shown right to left with a note that they are machine translated, and an article with no translation shows in English with a note saying so; missing: the Arabic and Russian texts are machine translations that a native speaker still has to review, most of the other texts the server writes (the validation messages of most modules, the texts of single findings, the headings of the other Excel lists) and the other 25 of Linto's help articles (all HSE) are still English in Arabic and Russian (the public user guide stays Turkish and English; an Arabic or Russian guide is a decision for the partners), the Hijri date and Arabic-Indic digits are not in the payment set or in other files than the cover, the review sheet, the Gulf certificate and the list exports, Excel keeps number and date cells as real numbers, and on the pages only formatted numbers and dates convert. | Rare | Partly in the app |
| Language groundwork for Arabic and Russian ★Normalises Arabic and Russian text for matching and holds stage, role and code names per language as project data. | Not found elsewhere | In the app |
| Project calendar ★Holds each project's weekend (Saturday and Sunday, or the Friday and Saturday week of the Gulf, or a custom one) and a dated list of holidays, and counts working days against them to set review due dates. | Not found elsewhere | In the app |
| Bilingual output ★Produces transmittals, review forms and register exports in two languages from the same record, keeping document numbers and revision codes left to right.Not yet: The transmittal cover (Excel and PDF), the review sheet (CRS) and the register export print in Turkish, English or both from the same record, with a project default per output, the owner's language and two lines or two columns; numbers, revision codes, dates and amounts are identical in every language, written text stays as written and return codes print with their meaning from the project's table; Arabic and Russian are printed too, alone or in two languages with English beside them, the Arabic Excel sheets and PDF run right to left (joined letters and a mirrored layout in the PDF, vowel marks not written), and a filled Arabic or Russian CRS can be loaded back; every other Excel list is in Turkish, English or both together (the same list is asked for in each language with the person's own session and the two files are laid together cell by cell: what is the same stays one cell, what differs holds Turkish then English); missing: the other lists in Arabic and Russian (their headings and words are not written in those languages), and a native review of the Arabic and Russian words. | Rare In enterprise suites | Partly in the app |
| Terminology sets per project ★Holds approval wording sets for EXPRO (Arabic and English), Russian and Turkish, editable per project.Not yet: Stage, role and review code names are an editable per-language map (en, tr, ar, ru) per project; the Term sets box on the Documents tab of Settings loads EXPRO (codes A to E, the reasons for issue as stages, roles; Arabic and English) or the Russian set (Согласовано, Согласовано с замечаниями, Не согласовано, last stage "В производство работ") in one step, changing names only while the credit of a stage and the effect of a code stay the project's own; missing: a native review of the Arabic and Russian wording (no published Russian EPC code table exists, the set is the closest the sources give). | Not found elsewhere | Partly in the app |
| Time log for transmittals, record updates and progress reports ★Measures time spent per transmittal, record update and progress report, and time to first transmittal, published with its method.Not yet: Measured from the app's own events: upload to issue in a transmittal, preparing a transmittal, site entry to signature, cut-off to an issued payment application (per event and as weekly medians), plus minutes per incoming transmittal and time to first transmittal; time logged by hand is kept apart and never mixed in; the contractor's pre-pilot figures are compared with the measured ones; a printable method note states how each is computed. A Scorecard tab works out four measures from the records, never typed and never editable (preparing and sending a transmittal; bringing the register up to date after an incoming transmittal, from the file being read to its being applied; the monthly progress report, from "Start the report" to its Excel file; days from the project's opening to the first transmittal); the customer's own times from before the pilot are entered once with their source, who gave them and when (a second replaces the first only with a reason, and the first stays on record); the median is judged by month against the success thresholds of the pilot settings (a limit or a reduction against the baseline, and the cases needed); a change to the thresholds after the pilot has started needs a reason and is counted; a case (a test project, a holiday) is left out only with a reason, audited, put back the same way, and stays on the list; the Excel file for the pilot review meeting carries a check value. Missing: a signed snapshot that freezes a month, a view per person; the monthly report file is made from the records as they are today, not as they were on the last day of an earlier month. | Not found elsewhere | In the app |
| Russian interface; SharePoint integration ★Adds a Russian interface and reads up to ten SharePoint document libraries per project, read only: a timer takes only what changed through Microsoft Graph and stages it; the staged files are shown as the CDE import's preview and reach the register only when a person confirms it.Not yet: The Russian interface is in the app, machine-translated and waiting for a native speaker's review. SharePoint, read only: a project administrator enters the customer's own Entra ID app (tenant id, client id), the site and the library, tests the connection and chooses a read interval; the app's secret and the day it ends are settings of the server, in no table and on no page; a timer or "Read now" takes only what changed (a delta query) and stages it; the staged files show in the CDE import's own preview (column matching, status words, checks) and reach the register only when a person confirms it; a file removed in SharePoint is reported but its document is never deleted; an unreadable file is listed with the reason and can be retried; every read is in a run log and the audit trail; reading stops by itself the day after the secret ends; nothing is written to SharePoint and no file content is fetched; a project can read several libraries (each with its own staging, preview, run log and schedule), write its own rules that give a file with no discipline the discipline of its folder (a discipline typed in SharePoint is kept), and let the app sign in with a certificate instead of a secret. Missing: SharePoint has only been run against a stand-in for Microsoft Graph, not a live tenant (the Sites.Selected grant, real column names, a guest account in the owner's tenant and a certificate accepted by a real Entra app are unproven); file content is not copied, only the details; a folder rule gives the discipline only, with no wildcards; there is no combined preview across libraries, no change notifications (only the timer), and OneDrive and sovereign clouds are not read. | Not found elsewhere | Partly in the app |
| Single sign-on (OpenID Connect)Signs people in through the company's own identity provider (Entra ID, Google Workspace, Okta, Keycloak), limited to its e-mail domains; accounts for invited people only or for anyone in the domains; an SSO-only mode that turns passwords off and leaves the second step to the provider. SAML 2.0 sits beside it: the provider's sign-in address, entity ID and signing certificate (up to three, for a rollover), the answer checked for signature, issuer, audience, time window and that it answers a request this server made, one protocol at a time per company, the same domains, test sign-in and SSO-only rules. With the company's own key pair it signs its requests, opens encrypted assertions, signs out at the provider too and ends sessions when the provider asks, and lets the provider start a sign-in when the company allows it.Not yet: OpenID Connect is done and SAML 2.0 is tried against a pretend provider that signs real XML, refusals included; also done against the same pretend provider: the company's own key pair (the private key sealed, never shown), signed sign-in and logout requests, encrypted assertions (and a switch to refuse plain ones), single logout from both sides (signed messages only) and a sign-in the provider starts (each assertion accepted once). Missing: a run against Entra ID, Okta, ADFS or Keycloak with their own signing and encryption settings, logout of every application at once, and the SOAP binding. | Common In enterprise suites | Partly in the app |
| In-app help and assistant ★A "How it works" panel on every page and a hand-written article for each task, in two languages, with numbered steps, sample questions and the roles that see it. Found by a deterministic search that folds Turkish letters, weights the sample questions and knows synonyms (hakedis, progress payment and IPC are one thing): no model, so the same question always gets the same answer. A round button that can be dragged and muted, a what's-new list, and a guide that every visible change must update. | Rare | In the app |
| Ask the project: exact answers ★The assistant answers counts, lists, what is late and the status of a document from the records themselves, by SQL and the pages' own rules, with no AI: documents with the owner and overdue by discipline, system or originator, a document's status, revision, lifecycle stage and where it is in a review, my waiting review steps, open RFIs and letters past due, transmittals sent or received in a period, progress and earned value by system against plan, the latest payment application (only for roles that see cost), open punch A items by system, counts and top N, in Turkish and English. Every word of a question is accounted for: a recognised word changes the query (tested), and for a word no handler takes the assistant says which one and offers the question without it (or, when the AI is on, sends the question to it). It knows the page and the open record, so "what is holding this one?" works on a document. Each answer links to the page and the records; a bad answer becomes a support report with the question, the answer and its sources in one press. The conversation stays in the browser tab for the session. | Rare | In the app |
| Guided tours ★Press "Show me" on an article and a lit window moves over the real element of each step with a sentence about it. A test checks that every tour still points at something the application renders. | Rare | In the app |
| Onboarding by role and the training recordEach job (document control, engineer, reviewer, site, planning, cost, and the owner's, a subcontractor's and a vendor's people) has an ordered path of help articles and guided tours, with a default the project administrator can reorder, shorten or extend with the project's own procedures (a document of the register or a link) and a link to a short video. A person sees it as "Your first week" (on first entry to the project, in Linto's help menu and on the Training page); a step is done when its tour is followed to the end or the person confirms they read the article, and nothing blocks their work. The training record shows who completed which step and when, and who has not finished once the days set after joining have passed (a setting); the administrator sees it under Members and downloads it as Excel, and every completion is an audit entry. Ten main tasks have a short training video (1 to 2 minutes, filmed in the real application, in English and Turkish, with subtitles) that opens from the help article, the user guide and the step of the path; the other articles have none yet, and the page cannot tell whether an article was really read, it records the person's confirmation. | Rare | In the app |
| Feedback desk ★Report a bug, ask for something or ask a question from any page. The page attaches by itself a screenshot, the page, the project, the open record, the last 25 clicks as element names (never typed values), the last 12 browser errors, the browser and the version. States: new, in review, ready to test, closed by the reporter, won't do with a reason. Two-way messages, unread counts both ways and e-mail notices. A report is visible only to the person who made it, their company's administrators and the support role. | Rare | In the app |
| WebhooksYour own systems hear what happens in the project. The project administrator adds an https address (public internet only: private, local and link-local addresses are refused, again at every delivery), picks from ten event kinds (document registered, revised, stage changed, review started and closed, transmittal issued and received, RFI answered, payment application issued, site entry approved) and gets a signing secret shown once. Each message is JSON with the event id, kind, time, project, the record's id, number and link and the e-mail of whoever did it, no file contents, signed with a timestamp (HMAC-SHA256). Failed deliveries are retried for 24 hours; an address that accepts nothing for 24 hours is paused and its owner e-mailed. Each webhook shows its last deliveries with the answer code, sends a test event and sends one event again. Every change is audited, and an owner's fence is respected. Not yet: filters beyond the kind, Zapier or Power Automate adapters. | Common In enterprise suites | In the app |
| Project dictionary: WBS, CBS, PBS, OBS, discipline and document type codes in one place ★One language for every process: the project's breakdown structures are data in one place. The WBS, CBS (the cost codes), PBS (area, unit, system, subsystem), OBS (companies and roles), disciplines, document types, tag classes and the project's own lists each hold codes with a name per language, a parent (a tree), a keeper, a status (active, or retired with the code that replaces it) and a description. The lists the app already had are views of it, and the values records already use become codes without loss. Once a structure holds a code it is checked: documents, site items, cost lines, commitments, tags, inspections, RFIs and changes have to use one of its codes, free text is refused with the reason in both languages, and a retired code is refused for new records with its replacement suggested. Mappings (WBS to CBS, PBS to WBS, discipline to document types, document type to number mask, tag class to VDRL requirements) may be one to many and their gaps are listed. Responsibilities (RACI) are set per WBS element or document type from the OBS, one accountable party, a WBS element taking its parent's, and are readable from the API. The whole dictionary goes to and from one Excel workbook (a sheet for each structure, mappings and RACI) with a preview and a confirmed apply, plus an empty template to hand a project before it starts. The revision scheme is a project setting (letters then numbers, ISO 19650, or an issue number with a review letter such as 002-B, with separator and widths): the next revision and review letter are worked out, and the CDE import and transmittal matching read the scheme. A health check lists codes used nowhere, records using retired codes, structures with no mapping and two codes with the same name. Every change is audited. Not yet: review workflows and notices do not use the RACI by themselves, and imports record what the source says rather than checking codes. | Rare | In the app |
| Published price list ★Publishes prices openly. | Rare In enterprise suites | Phase 1 |
Packages
One price per project, not per seat.
Paid per project and month. The owner, subcontractors and vendors join free. Prices are set with our first customers during early access, so every start begins with a call and a pilot.
For document control
Record
Price on request
- Master document register with Excel import
- Owner, contractor and vendor numbers
- Owner returns from twelve CDEs (Excel or CSV)
- Project inbox: e-mail kept as evidence
- Search inside files, scans included
- Project lifecycle, review codes and roles
- Transmittals in and out, with response dates
- Multi-step review and comment resolution
- Audit trail and two-step sign-in
Recommended
Control
Price on request
- Everything in Record
- Progress from documents, versioned rules of credit
- Earned value and the S-curve
- P6 schedules in and out, DCMA 14 check
- Change, budget and commitment registers
- Progress payments, including FIDIC and the Turkish hakediş set
- Site app for daily reports and inspections
- AI answers with sources; classification and comment merging next
For handover and operation
Handover
Price on request
- Everything in Control
- Tag register linked to documents and equipment
- Owner handover checks, CFIHOS export
- Plant data beside the asset, read only
- Maintenance plan from handover data
- On-premise installation available
Packages describe the product as it is being built. The comparison above shows what works today and what comes next.
Pilot
Start with one work package.
Twelve weeks beside your current reporting, on one system or discipline with an active owner review cycle. Your process does not change; we read copies of what you already produce.
- Weeks 1 to 2: set upYour register, schedule and owner transmittals imported; rules of credit agreed with your planner; today's reporting hours measured.
- Weeks 3 to 10: run in parallelWeekly cuts and a full payment cycle, compared line by line with your own figures.
- Weeks 11 to 12: resultsA report against success measures signed before we started, and a joint decision on what comes next.
Questions
Short answers.
Do we have to leave Aconex, SharePoint or P6?
No. The owner's system stays the owner's. Lintara reads its exports and writes nothing back to them. Schedules come in from P6 as XER files; progress goes back as an XER file your planner imports.
Is it finished?
No, and we will not imply otherwise. Document control, progress, payments, handover and plant data work in the application today; the comparison above marks every line as in the app, partly in the app (with what is missing said on the line) or still to come. The application runs as a private preview on sample data until the first pilot.
Who can see our data?
Only the people you invite, with the role you give them. Every change is recorded with who made it and when. During early access, real project data is used only in a pilot under a signed agreement, and returned or deleted at the end.
Is it secure?
Two-step sign-in with an app code or a passkey, single sign-on, sessions that end after inactivity, an audit trail of every change, encrypted secrets and limits on sign-in attempts are in place, and nightly encrypted backups run with a weekly restore test. We are not certified to ISO 27001 or SOC 2 today; the data-protection paperwork is drafted and goes through a lawyer before any customer data comes in.
Do the owner and our subcontractors pay?
No. You pay per project; external participants join free and without a limit.
Does it work with our numbering and the owner's review codes?
Yes. Number formats, review codes, document stages and role titles are settings of each project, with presets for common owner schemes.
Which languages?
English and Turkish today. The interface is built to add more; tell us which ones your project needs.
Does it send anything to the plant?
No. Plant data is read only. Nothing in the product writes to a control system.
Every deliverable, accounted for.
Early access: we are starting with a small number of project teams. Tell us about your project and we will set up a pilot together.