Features

The plan viewer, close up

Sheet PDFs render on a canvas with pin coordinates normalised to the sheet rather than the pixel size of whoever is looking, so a pin dropped on a phone lands in the same place on a desk monitor. Three taps get from a point on a drawing to the task, RFI, defect or note it stands for — the pin is a route into the record, not a sticky note that lives beside it. The same viewer and the same pin model serve facility floor plans through a shared mixin, so a maintenance request pinned on a floor plan and an RFI pinned on a construction drawing are the same mechanism wearing two hats, not two implementations that will eventually drift apart.

Drawing transmittals

A transmittal is the record that a drawing was actually sent — to whom, for what purpose, and on what date — which is what ISO 19650 asks for and what "we emailed it" is not an answer to. Once issued, a transmittal is immutable: the recipient, the drawings, the purpose and the date cannot be edited afterwards, only superseded by issuing again — because a record that can be quietly corrected after the fact is not evidence of anything. A transmittal also flags when a revision it carried has since been superseded, so it is visible when a recipient may be working from a drawing that is no longer current.

Why immutable A claim that turns on which drawing revision a subcontractor was working to is decided by the transmittal, not by memory. That only holds if the transmittal itself cannot move once it has gone out.

Inspection and test plans, and hold points

An ITP names the checks a piece of work requires, in order, against a stated acceptance criterion and standard — and the checks come in two kinds that ISO 9001 treats very differently. A hold point stops the work: concrete is not poured until the rebar inspection is signed off, and a pour that goes ahead anyway is the defect nobody can inspect afterwards, because it is inside the slab. A witness point only invites somebody — if they do not attend, the work proceeds and the record shows they were invited. Releasing a hold point needs either the inspection that evidences it, or a recorded waiver naming who authorised proceeding without one.

Waivers are recorded, not hidden Hold points do get waived on real jobs. A system that cannot record that honestly gets worked around instead of used — so a waived hold point still shows exactly who authorised it and why, rather than pretending the point was never there.

Health, safety and site records

• Permits to work — hot work, confined space, work at height, excavation, lifting. A permit cannot be approved until every mandatory precaution is confirmed, and it auto-expires the moment its validity window closes rather than waiting for somebody to notice. Permit-to-Work PDF.
• Incidents and near misses — root-cause investigation and corrective actions that gate closure, so an incident cannot be closed with its actions still open.
• Toolbox talks — with a signed attendance record.
• LTIFR — computed from the labour hours already recorded on the daily site logs, not typed in separately.

Permits, logs and inspections are worth nothing in money and matter enormously, so their approval rules match on kind rather than value: hot work and confined space want the safety manager, everything else the project manager.

Materials and site stores

Built on a connected stock record rather than a parallel inventory. Each project gets a real stock location. Material issues book stock out of the store into the works against a BOQ item, and waste is recorded as scrap with a reason — offcut, damage, spillage, over-order, loss.

The material position view puts budgeted, consumed, wasted and on-site quantities on one row per product, so over-consumption — the early signal of waste, theft or a mis-measured quantity — is visible against what was priced, while there is still a month left to do something about it. Issue Docket PDF.

Approvals and control

Fourteen modules had each grown their own approve button — a state field and a groups="…" attribute in a view. Two things were wrong with that, and the second is serious. A threshold could not be expressed at all: a variation of five thousand and one of five million took the same single click from the same person. And the rule was a UI instruction — groups hides a button, it does not stop the method being called.

A document becomes approvable by inheriting construction.approvable and answering two questions: what it is worth, and what kind it is. A rule matches a model, optionally a kind and a project, and a band of value, to a chain of steps. Each step is a record — which is what makes a single inbox across many document types possible: "waiting on me" is a query over steps, not a tour of every model.

The controls

• The check is in the method. _check_approved() is called from action_approve itself, so the rule holds wherever the call comes from — a button, a script, the RPC console, or a screen nobody has written yet.
• Segregation of duties. On by default: the person who raised the document cannot sign it. It can be turned off where it does not apply — a daily log approved by the person who wrote it is normal.
• Order. A step cannot be signed while an earlier one is outstanding, so a chain cannot be signed from the bottom up.
• A reason is required to reject. A rejection without one guarantees a second cycle.
• Refusals explain themselves. "Project manager has to approve this first", not "access denied", which teaches nobody what to do next.
• Delegation with attribution. A delegation names who is covering and for how long; the delegate's inbox fills with the approver's outstanding steps; and each signature records whose authority was used — decided-by and delegated-from are separate fields. The usual field fix is sharing a login, which destroys the audit trail exactly where it matters.

An example delegation of authority

Bands are inclusive at the bottom and exclusive at the top, so 0–50,000 and 50,000–250,000 meet exactly once. A rule naming a project beats a company-wide one, and a rule naming a kind beats one covering every kind — so a job with an unusual delegation of authority gets its own rules without disturbing the others.

Where the check sits, per document

Deliberately not in the engine Six models are wired up, not every model — moving another across is a small, explicit piece of work rather than something that happens by accident. A document no rule covers keeps its old behaviour, because a suite that refused to work until rules were written would only get the rules written badly and in a hurry. And there is no approve-by-reply: the WhatsApp alert carries the document and the value and links into an authenticated session, because a token in a message body that approves a quarter-million variation is a signature anybody who sees the phone can forge.

The longer argument, with the test output that started it →

QR and NFC asset tags

Every facility asset has a human-readable unique code such as AST-2026-00001, independent QR and NFC destinations protected by an unguessable token, an active / missing / retired tag state, optional storage of the physical NFC tag UID, a printable 70 × 50 mm label, an authenticated mobile landing page, and append-only scan events recording asset, user, time, method and assigned location. Tokens rotate when a label is lost or copied.

QR and NFC open separate Majal paths so scan history records which was used. The NFC payload is the asset's tag URL encoded as an NFC Forum NDEF URI record. Both tag URLs enter through Majal sign-in with a same-site return path: a new phone selects the locked database, signs in, and then continues to the asset — without exposing the database manager or bypassing record permissions.

Choosing the carrier

Majal's scan-event model is intentionally shaped to be compatible with GS1's EPCIS what, when, where and why, and with GS1 Digital Link identifiers, so assets can later be connected to supplier and owner information without reprinting the code. UHF RFID, BLE and GS1 event exchange are carrier choices for your estate — Majal implements the QR and NFC paths described above.

Document control

Client-branded English and Arabic document templates with sanitised rich-text editing. Submitting for approval creates an immutable HTML attachment and a SHA-256; a different named approver approves that exact revision; and issuing is allowed only while the approved checksum still equals the current immutable revision. Changing a company logo or address affects new rendering but does not alter the checksum or stored content of an approved revision.

Structured sheets cover BOQs, estimates, budgets, valuations, schedules and registers: quantity × unit rate per line, Freeze Revision recording the canonical SHA-256 and preventing edits, a manager-only Start New Revision, and CSV export with a UTF-8 BOM for Arabic and formula-like text prefixed to prevent spreadsheet formula injection.

Said explicitly The optional company approval mark is an internal visual mark. It is not a qualified electronic signature, and the documentation separates the two rather than letting a client assume. The structured-sheet editor is deliberately structured and auditable; it is not a lossless arbitrary XLSX or DOCX editor.

Platform, language, administration and recovery

Arabic and RTL

Arabic translations ship with the modules and the database is initialised with the Arabic locale in the documented install. RTL is handled deliberately in the interface layer rather than left to the browser's default mirroring. It also shows up in small engineering decisions: BIM unit-of-measure categories are matched by xmlid rather than by translated name, precisely so quantity matching does not stop working in Arabic; and CSV exports carry a UTF-8 BOM so Arabic opens correctly in a spreadsheet.

Client administration without a permission grid

Six Majal roles — Platform Owner, Company Administrator, Operations Manager, Project/Facility Manager, Engineer/Supervisor, Field User/Technician — replace the raw clear capability tiers, each scopeable to Construction, Facilities, or both. Twelve audited optional capability tiers add Procurement, Inventory, Finance, HR, Website and AI administration; one tier per family; each with a minimum role; and high-risk Finance, HR and Website administration requires Platform Owner approval.

Enforced on the server: a Company Administrator cannot grant Company Administrator or Platform Owner; no administrator can change an account at or above their own rank; users cannot deactivate themselves; the last active Platform Owner cannot be deactivated; client administrators cannot bypass role boundaries; and access and activation changes land in an immutable administration audit. HR packs are explicitly isolated from Facilities administration, because the upstream HR role normally implies Maintenance Administrator.

Verified recovery

A daily job keeps seven curated archive slots — today, yesterday, the day before, weekly, two-weekly, monthly and quarterly checkpoints. Each ZIP holds a transaction-consistent dump.sql, the filestore/ with every uploaded drawing, photo and attachment, and a manifest.json recording platform, PostgreSQL and installed-module versions — with a SHA-256 stored in Majal and checked again before download or restore.

Restore is two-step by design, because a live web process must never be able to replace its own database: a Platform Owner prepares a restore and gets a one-time code that expires in two hours, and a deployment operator runs the script offline. The script validates code, expiry, path, checksum and ZIP contents, restores into a replacement database, restores the filestore, validates the installed-module table, and rolls the original database and filestore back automatically if validation fails.

Not a whole DR strategy Seven local points are fast operational rollback. Off-site encrypted copies, immutability against application credentials, monitoring, client-specific RPO/RTO and a rehearsed quarterly restore drill are all documented as things a deployer must add. Why the distinction matters →

Security baseline

Majal uses a maintained authentication and authorisation foundation; it does not implement a second password or session system. The shipped profile locks the database selector to one database, disables database listing and the browser database manager, runs the web application as a PostgreSQL role with no superuser, database-creation or role-creation privileges, and installs Majal's password policy, passkey and TOTP / email-MFA modules with a 12-character minimum. The documentation is explicit that email-based 2FA must not be enforced before mail delivery is verified, because doing so can lock out every user.

Majal Intelligence

A permission-aware bilingual copilot that searches through the current user's environment, so normal access controls and record rules stay active. Local Ollama is the free default; Kimi, OpenAI, Gemini and Claude are company-managed bring-your-own-key options behind one provider-neutral gateway, with keys encrypted at rest and never returned to the browser. Conversations are private to their owner, usage is audited and limited per user and company, provider endpoints are fixed so the server cannot be turned into an outbound proxy, and operational records are treated as untrusted prompt content.

Deliberately read-only The first release can summarise and recommend. It cannot approve, sign, pay, close, delete or modify operational records, and every answer is labelled as generated material.