Engineering workspace
Building intelligence, organised.
A structured environment for technical due diligence, building condition assessment and investment planning. Start with a project, record evidence, assess risk and build a defensible client report.
A simple way to get started
New to the workspace? Follow these four steps.
You do not need to complete everything at once. Start with the building details, then add inspection notes as you go.
Active projects
2
Across reference asset classes
Recorded findings
4
Evidence-led observations
High-priority risks
2
Require action or further investigation
Indicative CAPEX
DKK 1.8m
Illustrative sample estimate
Project portfolio
Illustrative projects · replace with live assignments
| Asset / project | Type | Stage | Priority |
|---|
Delivery workflow
v1.001 · Define scope
Asset, purpose, boundaries, reliance and exclusions.
02 · Review documents
Identify missing evidence and information gaps.
03 · Inspect & record
Component-based inspection with traceable evidence.
04 · Assess & quantify
Risk, uncertainty, remedial actions and CAPEX.
05 · Report & review
QA, executive summary and client issue.
Operating principle
Separate observed facts, technical interpretation and recommendations. Do not convert missing information into assumed compliance.
Separate observed facts, technical interpretation and recommendations. Do not convert missing information into assumed compliance.
Portfolio management
Projects & assets
Register the asset, define the assessment context and establish the project boundary before technical work begins.
Registered buildings
2 records| Project | Building type | Location | Stage |
|---|
Add a building
Step 1Keep it simple. Only the building name is required. You can add the other details later.
Building-specific guidance
Inspection suggestions for this building
Select a registered building. Its construction year will be matched to the Danish typology library to suggest what to verify before and during inspection.
Register a building and enter its construction year to see tailored inspection suggestions.
Field assessment
Site checklist
Use this list while walking around the building. Tick an item when you have checked that area. It is fine to mark an area as not accessible in your notes rather than guessing its condition.
Selected building guidanceNo building selected
Register a building with its construction year to see inspection priorities here.
0 completed
20 checklist items
0% completion
Tick only what you have actually checked
Choose a part of the building
Select an area on the drawing or use the buttons. The checklist below will show the relevant items.
Inspection guide
Choose a building area
Select an area above to see practical questions and evidence to collect.
Learn what to look for
Typical warning signs
Choose an area on the diagram to see common visible warning signs. These examples help guide inspection; they do not establish a diagnosis.
Inspection checklist
Inspection protocol
Access & visibility
Record inaccessible, concealed or obstructed areas. A visual inspection does not establish the condition of concealed construction.
Evidence quality
Use overview, context and detail photographs. Link readings to instrument, date, location and conditions.
Sampling
State sample size and selection logic. Do not generalise isolated observations without a defensible basis.
Safety
Do not access unsafe roofs, confined spaces, electrical installations or suspect hazardous materials without suitable competence and controls.
This checklist is a scoping aid, not a statutory inspection checklist or substitute for specialist surveys, destructive testing or legally required inspections.
Field data & diagnostics
Measurement register
Record readings from any suitable instrument, link them to a building and location, and document how you interpreted them. The application will help organise the evidence; it will not automatically certify performance or compliance.
0Measurements recorded
0Need investigation or repeat
0Specialist reviews flagged
Step 1 · Enter the reading
New measurement
Keep one record for one measurement point or result. For a series, add separate readings or describe the series and attach the processed result in your project evidence. Record the conditions so the result can be understood later.
Step 2 · Review the evidence
Diagnostic review
Select a saved result from the register below. The review brings together the instrument's purpose and limitations with the conditions and assessment you recorded.
No measurement selected
Your review will appear here
Save a measurement, then select “Review” beside it to inspect the record.
No automatic pass/fail. Limits depend on the question, method, equipment, building use, applicable standard and measurement conditions. The engineer must select and justify the relevant criteria.
Project evidence
Recorded measurements
| Date / ID | Building / location | Parameter | Reading | Instrument | Assessment | Review |
|---|---|---|---|---|---|---|
| No measurements recorded yet. Use the form above to add the first result. | ||||||
Product architecture
Platform, security & deployment
A two-stage plan: operate the prototype at zero recurring cost now, then add secure shared cloud services when the business is ready.
Current status: Phase 1 is a zero-recurring-cost prototype deployment. The app will be hosted as a static site on Cloudflare Pages Free, with source code in a private GitHub Free repository. Project data remains in this browser's local IndexedDB and must be moved between devices using manual JSON export/import. There is no cloud database, login, automatic sync or encrypted client-file storage. No hosting account, repository or deployment has been connected yet. Use sample, public or thoroughly anonymised data only.
Phase 1 · temporary free setup
Cloudflare Pages Free + GitHub Free
Publish the app shell at no monthly cost while keeping all project records local to each device.
Cloudflare Pages FreeStatic HTML, CSS and JavaScript hosting with a free pages.dev address. No backend functions or paid add-ons in this phase.
GitHub Free · private repositoryVersion-controlled application code only. Do not store client files, project data, backups, credentials or secrets in the repository.
Browser-local project storageIndexedDB on each device. Windows and iPhone will not share data automatically; use Export backup and Restore backup to transfer a JSON copy manually.
What this gives us: one published app URL that can be opened on Windows and iPhone, free source-code versioning and repeatable deployment when code changes. The deployment package includes a web app manifest, app icons and a service worker for install support and offline app-shell loading. Installation and offline behaviour must be tested after HTTPS deployment.
What it does not give us: user accounts, MFA, shared cloud storage, device synchronisation, team permissions, encrypted project backups or an EU-only guarantee for all traffic metadata. Cloudflare's static delivery network is global.
Data rule for Phase 1: use sample, public or thoroughly anonymised test information only. Do not upload client drawings, confidential reports, personal data, access codes or security-sensitive building details. JSON backups are not encrypted by this prototype; store them securely and keep a separate recovery copy.
1 · Connect GitHub
Create a private repository for application code only and authorise access to that repository.
2 · Connect Cloudflare Pages
Choose the Git integration, select the private repository and deploy the static app. Git integration cannot later be changed to Direct Upload for that Pages project.
3 · Test both devices
Check the published URL on Windows and iPhone, then add and test the PWA manifest, service worker and install flow.
Target system overview
One workspace · several secure services
The interface stays simple. Data, access control, file handling and synchronisation sit behind it.
1 · User devicesWindows browser
iPhone installable PWA
Offline working view
iPhone installable PWA
Offline working view
→
2 · Secure application layerSign-in and MFA
API and permissions
Input validation
Sync queue
API and permissions
Input validation
Sync queue
→
3 · EU / EEA cloud environment
Relational project databaseProjects, assets, findings, measurements, risk and CAPEX
Private document storageDrawings, reports, photos and attachments
Audit, backup & monitoringChange history, recovery and service health
The hosting region must be confirmed for the primary database, document store, backups, logs and support access. “EU hosting” must cover the full data flow, not only the web server.
Phase 2 · future production platform
Appwrite Cloud · Frankfurt (FRA)
The proposed managed stack for when shared projects, secure client records, multiple users and cross-device synchronisation are commercially justified.
Region: Frankfurt · FRAAPI endpoint: https://fra.cloud.appwrite.io/v1Installable PWA: Windows + iPhoneData layer: native PostgreSQL
Appwrite SitesHosts the static web app / PWA, custom domain and TLS. The static interface contains no client project data.
Appwrite AuthIndividual accounts, sessions, team membership, email verification and TOTP / recovery-code MFA.
Appwrite FunctionsServer-side API for validation, permissions, report snapshots, audit events and controlled database operations.
Native PostgreSQLStructured engineering records, relationships, transactions, reporting queries, migrations and database-level row security.
Appwrite StoragePrivate buckets for photographs, drawings, reports and client files. Store file metadata and version links in PostgreSQL.
Realtime + PWA syncOptional live updates for team work. Offline edits are queued on the device and reconciled through the server.
Why this stack: Appwrite documents Frankfurt as an available region for its core services. Its September 2026 release added native PostgreSQL to all Appwrite Cloud regions, with database storage, backups and replicas tied to the project's selected region. Sites can host static apps and PWAs, while Auth, Storage and Functions are available in the same platform. This is a coherent first deployment for a small engineering consultancy; it avoids running and patching a self-managed server. Regions · Native PostgreSQL release · Sites hosting
Data-location boundary: choose the specific Frankfurt region, not a generic region group. Keep user data, database requests and private files on the Frankfurt services. The public PWA shell may be delivered through the global edge network; do not embed personal data in static assets or cache authenticated API responses or client files at the edge. Verify support access, logs, telemetry, billing data and all subprocessors through the current DPA before production use.
Security model to implement
Sign-in and membership
Appwrite Auth identifies the user. Team membership and project role determine what the person may do.
Server-side authorisation
Functions validate the session, organisation membership and project assignment for every write or sensitive read. Never expose service credentials or database passwords to the browser.
PostgreSQL row-level security
Enable RLS and enforce organisation_id and project_id boundaries in policies. Test access with two separate client organisations and every role.
Private document access
No public buckets. Check permissions before issuing short-lived access to a file; log upload, download, replacement and deletion events.
Proposed PostgreSQL record groups
Organisation & access organisations, users, memberships, roles and project assignments.
Property & inspection projects, buildings, components, checklist entries, observations, photographs and measurements.
Engineering decisions analysis records, risk assessments, actions, investment scenarios, work packages and CAPEX assumptions.
Documents & traceability document metadata, immutable file versions, review records, information requests and source-to-finding links.
Reporting & audit report versions, issued snapshots, reviewer sign-off and append-only audit events.
Tenant key on every business record: organisation_idProject key: project_idFile bytes stored separately from SQL recordsIssued reports saved as immutable snapshots
Phase 2 cost review — not approved: Appwrite pricing and the required database, storage, backup, email and domain costs must be rechecked when production deployment is approved. No subscription or paid service is authorised in Phase 1. Current pricing
Vendor due diligence still required: obtain and review Appwrite's DPA, current subprocessor list, data-transfer terms, support-access model, retention/deletion commitments and backup restoration procedure. Appwrite describes its Cloud services as GDPR-compliant and provides a DPA, but the application owner remains responsible for its own processing, permissions, retention and client contracts. Do not interpret a Frankfurt region selection as proof that every support or operational data flow stays in the EU. Appwrite GDPR / DPA guidance
Data design
Core project data model
| Record group | Purpose | Relationships |
|---|---|---|
| Organisation & users | Company tenancy, user identity and membership. | Users receive roles within an organisation and project. |
| Projects & assets | Client, instruction, property, building and components. | One project can contain multiple buildings and assets. |
| Inspection evidence | Checklist, observations, photographs and measurements. | Each record belongs to a project and, where applicable, a building component. |
| Technical assessment | Analysis, risks, confidence, actions and recommendations. | Assessments cite the records and evidence on which they rely. |
| Investment planning | Work packages, cost ranges, scenarios and assumptions. | Measures can link to findings, risks and asset components. |
| Documents & evidence links | File metadata, revisions, reviews and source references. | Files are stored separately; links connect them to findings and conclusions. |
| Reports & audit history | Report versions, sign-off, issue status and event history. | Issued reports retain a snapshot of their source records and revision. |
Access design
Proposed user permissions
| Role | Typical access |
|---|---|
| Organisation owner | Manage organisation, billing, users, projects, security settings and all records. |
| Project administrator | Create projects, invite team members, assign roles and manage project records. |
| Engineer / inspector | Create and edit assigned project records, upload evidence and draft reports. |
| Technical reviewer | Review evidence, calculations, risks and report versions; record QA sign-off. |
| Client viewer | Read only the selected, issued deliverables and specifically shared documents. |
Permissions must be enforced by the server for every request and file. Hiding a button in the interface is not access control.
Security baseline
Controls required before client data
Identity & account security
Individual accounts, multi-factor authentication, secure recovery and prompt removal of access when a person leaves.
Organisation and project isolation
Server-side tenant and project checks on every database and file operation; test that one client can never access another client's records.
Encrypted transfer and storage
HTTPS/TLS in transit; encryption at rest for database, file storage and backups; secrets kept outside the application code.
Private file access
No public document buckets. Use short-lived authorised links, file type/size checks and malware scanning before files become available.
Audit and recovery
Record who changed key records and issued reports. Test backups and restoration, not just backup creation.
GDPR and operational governance
Questions to resolve before hosting
Controller / processor roles
Establish who determines the purposes of processing and which providers act as processors for each client engagement.
Data processing agreement
Review the provider's DPA, subprocessors, breach process, support access, data export and deletion provisions.
Retention and deletion
Define project retention, legal holds, client handover, account closure and deletion of files, backups and audit records.
Incident handling
Document access revocation, incident investigation, notification responsibilities and restoration procedures.
Data location verification
Check database, file storage, replicas, backups, telemetry and support access locations; assess any international transfers.
Offline and cross-device behaviour
How synchronisation should work
The user should be able to inspect and record information in the field, even when mobile connectivity is poor.
1
Work locallyThe installed PWA stores authorised project data and queued changes on the device.
2
Queue each changeEach update receives a unique ID, project scope, timestamp and version so it can be safely retried.
3
Synchronise securelyWhen online, the client sends queued changes through authenticated APIs. File uploads resume or retry separately.
4
Resolve conflictsServer versions detect simultaneous edits. Critical engineering records should be compared and resolved, not silently overwritten.
Important design choice: offline access must be limited to projects already authorised for that device. A remote permission revocation cannot erase data from a disconnected device immediately; define device protection, local retention and revocation handling before enabling offline client files.
Implementation governance
Deployment-readiness checklist
Tick an item only after it has been configured and independently verified. This is a planning checklist, not an automated security test.
Checklist progress is saved with the local workspace as a planning record. It does not prove that any cloud control has been implemented.
Next build sequence: select and review the hosting provider → configure authentication and organisation isolation → create the database and private file store → migrate the current project records → implement the sync API and offline queue → test security, recovery and mobile installation. Do not use real client files until the security and data-protection controls have been verified.
Project information & evidence
Documents & evidence
Keep drawings, reports, maintenance records and other source material organised. Track revisions, record what you reviewed and link each source to the finding, measurement or calculation it supports.
How to use this workspace: upload the source file, record its revision and origin, review its relevance, then add a page or section reference when it supports a technical record. The application does not automatically read or extract document content.
0Documents registered
0Current versions
0Not yet reviewed
0Open information requests
Step 1 · Add source material
Upload a document
Keep the original filename. Add the type, revision and source so another reviewer can identify the document later.
Files and records are saved in this browser on this device when local storage is available. They do not synchronise to other devices and are not encrypted by the prototype. Export periodic JSON backups. Do not upload confidential, personal or security-sensitive client material.
Step 2 · Record the review
Document review
Mark whether the document is relevant, contains an issue or does not apply. Add the page, drawing number or section when useful.
Review discipline: “Received” does not mean “reviewed”. Record what the document actually covers and distinguish a missing document from a document that was reviewed but contains a gap.
Project evidence
Document register
The selected project is shown below. Superseded versions remain in the register for audit history.
| Document / file | Category | Revision / dates | Version state | Review status | File |
|---|---|---|---|---|---|
| No documents registered for this project yet. | |||||
Step 3 · Identify missing information
Document request list
Record what is needed, why it matters and who should provide it.
Update the request status when information arrives, is confirmed unavailable or is no longer required. Upload the received file separately and link it to the relevant request by its title.
Project gaps
Information request register
| Requested information | Priority / due | Status |
|---|---|---|
| No information requests recorded. | ||
Step 4 · Make conclusions traceable
Evidence links
Link a source document to a finding, measurement or calculation. Enter the page, drawing number or section yourself; the application does not extract these references automatically.
| Source document | Linked record | Source reference | Technical note |
|---|---|---|---|
| No evidence links recorded yet. | |||
Prototype data boundary: This is a structured register, not a secure document-management service. Attachments, revisions, review notes and evidence links are stored locally in this browser when available. They are not synchronised between devices or automatically backed up to the cloud. Export JSON backups regularly; do not use confidential client material.
Building performance calculations
Analysis workspace
Turn measurements and building information into transparent engineering calculations. Choose a question, enter the inputs and review the assumptions before using the result in an assessment.
Choose what you need to assess
Each tool handles one defined calculation. You can return to the measurement register to review the original field data.
Calculation output
Result & interpretation
Choose a calculation and enter the required information. Your result, equation and key limitations will appear here.
Project evidence
Saved analysis records
| Date | Building | Analysis | Key result | Basis |
|---|---|---|---|---|
| No calculations saved. Calculate a result and select “Save to project record”. | ||||
Engineering boundary: These are transparent calculation aids, not a dynamic building simulation, hygrothermal model, certified energy calculation or compliance assessment. Confirm the method, material data, boundary conditions, applicable standard and uncertainty for the specific project before relying on a result.
Evidence register
Findings & observations
Record what was observed, where it was observed and what remains uncertain. One record per distinct issue is preferred.
Recorded observations
4 records| ID / component | What was seen | Severity | Photos | Next step |
|---|
Add an observation
Step 3Start with what you can see. Describe the condition first. Possible causes and recommended actions can be added separately. Only location and observation are required.
Attach inspection photographs
Optional evidenceSimple photo sequence: take one overview, one context photo and one close-up. Choose the images below, then save the observation in the form above. Saved photos are stored locally in this browser on this device; export a backup to preserve them.
Images only · maximum 5 MB per image. Do not upload confidential or identifiable information into this prototype.
Decision & investment support
Risk & investment analysis
Turn inspection findings into transparent risk assessments, then compare investment packages. Review likelihood, consequence and evidence confidence before deciding what should be investigated, repaired or upgraded.
0 high / critical risks
0 registered risks
0 draft assessments
0 life-safety flags
Step 1 · Prioritise the issue
Risk register
Every observation starts as a draft screening score. Select “Review” to enter a project-specific assessment.
| Finding / issue | L | C | Score | Confidence | Priority |
|---|
Step 2 · Record your judgement
Review a risk
Assess the credible technical consequence, not only how visible the defect looks.
Scoring guidance
Use the same scale consistently
1 · Rare / MinorExceptional occurrence; negligible effect or local repair.
2 · Unlikely / LimitedNot expected in normal conditions; limited disruption or cost.
3 · Possible / ModerateCould occur; material repair, performance or operational impact.
4 · Likely / MajorExpected or recurring; significant damage, disruption or cost.
5 · Almost certain / SevereImminent or established; severe loss, major failure or safety impact.
Confidence is recorded separately and is not multiplied into the risk score. Low confidence increases the need for investigation; it should not make a potentially severe consequence look less important. The 1–25 matrix is a project screening convention, not a statutory Danish classification.
Step 3 · Compare investment choices
Renovation & investment scenarios
Build three packages using cost ranges and explicitly stated benefits. Assign each work package to the scenario in which it belongs.
| Scenario | CAPEX low | Base estimate | CAPEX high | Annual saving | Simple payback |
|---|
How to read this: Low / base / high are entered estimate boundaries, not statistical confidence intervals. Energy and monetary savings are user-entered assumptions. Simple payback is base CAPEX divided by annual cost saving; it excludes financing, discounting, price escalation, tax, replacement cycles and residual value. No saving is inferred from a defect or from the building's age.
Step 4 · Define a work package
Add an investment measure
Link it to a finding where relevant. Enter a range when the scope is uncertain.
Project evidence
Scenario work packages
Review the measures assigned to each scenario. Remove or revise a package when its basis changes.
| Measure / linked risk | Scenario & timing | CAPEX range | Annual saving | |
|---|---|---|---|---|
| No work packages entered yet. Add a measure to compare scenarios. | ||||
Decision discipline: Risk priority does not automatically determine the investment decision. Consider legal and life-safety duties, evidence confidence, access, operational disruption, dependencies, service life and the owner's objectives. Record the reason for selecting or deferring each measure.
Budget and investment planning
Future building costs
Turn building issues into an initial view of likely repair and replacement costs. These figures are planning allowances, not contractor quotations; show a range when the scope is uncertain.
Immediate / 0–1 year
DKK 420k
Urgent works and investigations
1–5 years
DKK 880k
Planned renewals and repairs
5–10 years
DKK 500k
Forecast lifecycle expenditure
Total indicative allowance
DKK 1.8m
Excluding VAT unless stated otherwise
CAPEX schedule
Illustrative DKK| Component / work | Timing | Allowance | Basis |
|---|
Costing assumptions
Cost basis
State date, location, price source, VAT treatment and whether fees, preliminaries and contingencies are included.
Estimate class
Separate measured quantities and quotations from benchmark allowances and order-of-magnitude estimates.
Uncertainty
Show exclusions, access constraints, hidden conditions, inflation and design development risk.
No false precision
Use appropriate ranges when scope or quantities are uncertain. Validate against Danish market rates before client issue.
The sample figures are placeholders to demonstrate the model. They are not current Danish contractor prices or cost advice.
Client deliverable
Client report builder
Assemble a project-specific Technical Due Diligence report from the evidence already recorded. Review every section and edit the scope, executive summary and limitations before issuing.
Report setup
Prepare the client document
Choose the building and complete the report details. The preview below refreshes when you build the report.
Measurement intelligence
Equipment & diagnostics
A practical guide to tools that can help investigate building condition, energy performance, indoor climate and technical risks. Choose the question first; then select a suitable instrument and method.
Start with the question you need to answer
The same instrument can be useful in different investigations. This guide helps you compare possible tools, understand what they can and cannot tell you, and decide when a specialist or laboratory is needed.
In your current toolkit · FLIR E8BlowerDoor + TectiteTesto 405i
Choose a diagnostic question or search the full equipment library.
Equipment guide
Select a tool to see how it is used
Each tool includes its purpose, useful applications, practical limitations and field notes.
How to choose the right instrument
1 · Define the question
What do you need to establish: presence, extent, cause, performance or compliance?
2 · Choose a suitable method
Check whether the instrument measures the property directly or only provides an indirect screening indication.
3 · Record the conditions
Capture location, time, instrument, settings, calibration status, environmental conditions and operating state.
4 · Interpret with care
Compare results with the right criteria and uncertainty. Escalate to testing, a laboratory or a competent specialist when necessary.
Measurement quality & safety
A measurement is only useful when the method, conditions and limitations are understood. A displayed number is not automatically a diagnosis or proof of compliance.
Calibration and checks
Follow manufacturer requirements; record serial number, calibration date and any field checks where relevant.
Competence and permissions
Electrical, fire, gas, refrigerant, asbestos and structural investigations may require specialist competence, authorisation or safe systems of work.
Evidence and repeatability
Use a documented sampling plan, representative measurement locations and repeat readings where appropriate.
Technical governance
Methodology & quality assurance
A controlled approach to scope, evidence, technical reasoning and professional reporting.
Danish construction knowledge · Edition 1
Building typologies & common defect patterns
Start with the approximate construction period and building type. Select a period to see common construction patterns, what to inspect and which investigations may help. These are working hypotheses for planning an inspection — not a diagnosis of an individual building.
Choose a period or search by construction feature.
Selected building period
Choose a period card to explore
You will see typical construction, possible defect mechanisms, inspection priorities and practical next steps here.
Danske Bygningsmodeller · 3D details ↗
Dansk Byggeskik · 1850–2000 archive ↗
Sikkerhedsstyrelsen · Inspection watchpoints ↗
Byggeskadefonden · Renovation guide ↗
Social- og Boligstyrelsen · Structural reuse guide ↗
BR example · 1930s apartment building ↗
How to use this library: Construction period is a clue, not proof of the actual build-up. Alterations, local practice and individual design matter. Confirm the building using original drawings, archives, visible details and, where necessary, targeted opening-up or specialist testing. Record uncertainty explicitly. This library is not a statutory inspection checklist.
Minimum QA gate before issue
Reference governance
Do not rely on an unverified standards list. Confirm current editions, amendments, national annexes, legal status and project applicability using authoritative sources.
Danish Building Regulations
bygningsreglementet.dk · Verify applicable BR18 provisions and guidance.
Danish Standards
ds.dk · Verify standards status and licensed text.
Danish Energy Agency
ens.dk · Energy policy, schemes and official guidance.
European Commission
energy.ec.europa.eu · EU building and energy policy.