Why should a document be a database record rather than a file in storage?

Because the questions asked about it are database questions. Which version of this report is current, who uploaded it, when, against which case, is it the one the decision was based on, and may this particular user see it. A file in a folder answers none of those. A record pointing at stored content answers all of them, and makes a signed temporary link the only way to retrieve the content - which is what stops a document being reachable by anybody who has the address.

How should versions of a document be handled?

As separate records with an order, not by overwriting. An engineer's report gets revised, a photograph is replaced with a clearer one, a certificate is reissued - and a decision made last March was based on the version that existed then. Overwriting destroys the ability to say what was in front of whoever decided. New version, previous version retained, and the decision referencing the version rather than the document.

These files have to be kept for years. Does that change anything?

It makes storage cost and retrieval both design questions. A claim closed five years ago is unlikely to be read and still has to be producible, so older content can move to cheaper storage as long as something records where it went and retrieval still works through the same path. The arrangement that fails is one where files were moved manually at some point and the application's links now point at nothing.

Laravel in Christchurch

Laravel development for Christchurch insurance, construction and agritech

Q: Our claim documents are uploaded by contractors and customers. What is the risk?

That the file is not what its extension says it is. An upload directory served by the web server, containing a file the uploader controls, is the oldest way to run code on somebody else's server - and it is still how it happens. Content goes outside the web root or into object storage, filenames are generated rather than accepted, the type is verified by inspecting the file rather than trusting its name, and nothing is served directly. That is covered properly in the piece on uploads that become shells.

A Laravel development company for Christchurch insurance, construction and agritech firms. Documents as records rather than files, uploaded by people outside the organisation.

Updated November 4, 2026

A Christchurch claim, construction project or compliance file is mostly attachments. The structured data describes it; the photographs, engineers' reports, certificates and correspondence are the substance of it.

That makes document handling the centre of these systems rather than a feature at the edge, and it is usually built as the thing it is not: files in storage, with the application keeping a path.

A Christchurch document is a Laravel record

Everything anybody needs to know about an attachment is a database question.

Which version is current. Who uploaded it and when. Which case it belongs to. Whether it is the version a decision was based on. Whether this particular user may see it. How long it has to be kept and whether that period has elapsed.

A file in a folder answers none of those, and a path stored in a column answers only the weakest one. A document record pointing at stored content answers all of them - and, importantly, means the content is retrieved through the application rather than by a URL. A signed temporary link generated after an authorisation check is the difference between a document that is protected and one that is merely obscure.

Christchurch uploads come from outside the organisation

In insurance and construction, a large share of files arrive from customers, contractors, assessors and engineers. None of those are inside the trust boundary.

The oldest failure on the web is still the most common one here: an upload directory that the web server will serve, containing a file whose name and content the uploader chose. The result is somebody else's code executing on your server.

The handling that prevents it is specific rather than clever. Content goes outside the web root, or into object storage. Filenames are generated rather than taken from the upload. The type is established by inspecting the file rather than by trusting its extension or the browser's claim. Nothing is served directly by the web server. File uploads that become shells covers the mechanism in detail, and it is worth reading before accepting a single photograph from a third party.

Versions, because a decision referenced one

Reports get revised. Photographs get replaced with better ones. Certificates get reissued. And a decision made eighteen months ago was based on whatever existed at the time.

Overwriting a document destroys the record of what was in front of the person who decided, which in a claims or construction context is the one thing a dispute turns on. So a revision is a new version with the previous one retained, and anything that references a document references a version.

That also makes an ordinary question answerable - what changed between these two reports - which otherwise requires somebody to have kept a copy in an email.

Years of retention, and content that still has to be findable

Retention here is measured in years, which turns storage into a design question rather than an operational one.

A claim closed five years ago is unlikely to be opened and still has to be producible on request. That means older content can move to cheaper storage, provided something records where it went and retrieval continues to work through the same path in the application.

The arrangement that fails is the informal one: at some point somebody moved old files to free up space, and the application's links now point at nothing. Making the move a recorded operation rather than a manual tidy-up is the whole of the fix.

The country-level ground for New Zealand - the privacy regime, data residency expectations, invoicing - is on the New Zealand market page.

A Christchurch claim is a timeline, not a status

A claim has a status column in most systems and it is the least informative field on the record.

What people actually need is the sequence - notified on the fourth, assessed on the eleventh, scope disputed, re-assessed, settled in part, reopened eight months later when something else was found. A status can only ever show the last of those, and the questions asked of a claim are almost always about the sequence. How long did assessment take. When did the estimate change and by how much. Was this reopened, and was the reopening related to the original damage.

So events are the record and the status is derived from them. That has a pleasant side effect: adding a new kind of event does not require a migration to the status enumeration and does not break a report that was filtering on it.

Reserves make the timeline financial as well as procedural. The estimated liability on a claim moves as more is known, and the history of those movements is what the business reports on - not just what the claim cost, but when it became apparent that it would cost that. A current figure overwritten each time loses exactly the information the actuary wanted.

Reopening is the case to design for rather than handle later. A settled claim that reopens is the same claim, not a new one, and its original settlement remains true. Modelling the reopening as a new claim loses the connection; modelling it as the claim returning to an earlier status loses the settlement. An event sequence handles it without either loss.

Laravel search inside Christchurch documents, not just across their records

The record says it is an engineer's report. The thing somebody needs to find is a sentence inside it, and metadata search cannot reach that.

Which means extraction is a pipeline stage. A document arrives, its text is extracted where it has text, and run through optical recognition where it does not - and in this sector a large proportion of what arrives is a photograph of a page rather than a document. The extracted text is stored with the document and indexed, and the quality of the extraction is itself worth recording, so that a search returning nothing from a scanned file is distinguishable from a file that genuinely does not mention the term.

Permissions have to follow the text. The extracted content is another copy of the document and is subject to the same access rules, which is easy to get wrong because the index feels like infrastructure rather than data. A search that surfaces a snippet from a document the user may not open has disclosed the document.

Extraction has to be re-runnable, because recognition improves and because a batch will eventually be processed with the wrong settings. If the original file is the authority and the extracted text is derived, reprocessing the archive is a job that runs over a weekend. If the extraction happened once at upload and the result was treated as the data, it is a permanent ceiling on how well search works.

Commercially

Scope fixed in writing before work starts, priced per project.

Invoiced by Codefacture Yazılım A.Ş. in Türkiye, in US dollars by bank transfer, with no Turkish VAT under the export-of-services exemption.