Kilospring

Publication register for regulated firms

A permanent address for every document you must publish.

Each document keeps one canonical address. Each publication carries the period it was in force, and the version it replaced stays on the record. Ask the register what was published on any date and it answers from the record rather than from memory.

Example Asset Management · Nordic Equity Fund · class A · XF0000000018 · KID, EnglishExample record

Address referenced by the document

https://documents.examplefunds.com/d/XF0000000018-kid-en

Resolves to the version that is current today, and to nothing else. Printed in the document, reported to the recipients that collect document links, held in your own records. The address carries no fund key and no ownership: a new share class, a change of manager or a rebranding leaves it exactly as it is. Every version below keeps its own dated address, which stays reachable after it stops being current.

The register for fund and aif managers →
Version history4 records
  1. 2026-04-21CurrentValid from 21 April 2026, open/d/XF0000000018-kid-en/2026-04-21
  2. 2025-03-1212 March 2025 to 21 April 2026/d/XF0000000018-kid-en/2025-03-12
  3. 2024-02-2828 February 2024 to 12 March 2025/d/XF0000000018-kid-en/2024-02-28
  4. 2023-01-099 January 2023 to 28 February 2024/d/XF0000000018-kid-en/2023-01-09
Example Digital Assets · EXAMPLE token · crypto-asset white paper, EnglishExample record

Address of the published white paper

https://documents.exampledigital.com/d/example-token-white-paper-en

A white paper is modified when the information behind it changes, and each modification is a publication of its own. The address stays as it is, the version in force today answers on it, and every earlier version keeps its own dated address for as long as anyone may ask what it said.

The register for crypto-asset service providers →
Version history3 records
  1. 2026-03-02CurrentValid from 2 March 2026, open/d/example-token-white-paper-en/2026-03-02
  2. 2025-07-1414 July 2025 to 2 March 2026/d/example-token-white-paper-en/2025-07-14
  3. 2024-12-3030 December 2024 to 14 July 2025/d/example-token-white-paper-en/2024-12-30
Example Capital · firm-level disclosure · sustainability risk policy, EnglishExample record

Address of the published disclosure

https://documents.examplecapital.com/d/example-capital-sustainability-risk-policy-en

A disclosure published in your own name is replaced rarely and referenced for years, which is exactly when nobody remembers what the previous wording was or when it changed. The address answers with what applies today, and the register answers with what applied on the date somebody asks about. Every version below keeps its own dated address, which stays reachable after it stops being current.

The register for other regulated firms →
Version history3 records
  1. 2026-01-19CurrentValid from 19 January 2026, open/d/example-capital-sustainability-risk-policy-en/2026-01-19
  2. 2024-06-033 June 2024 to 19 January 2026/d/example-capital-sustainability-risk-policy-en/2024-06-03
  3. 2022-12-1919 December 2022 to 3 June 2024/d/example-capital-sustainability-risk-policy-en/2022-12-19

Where it is used

One register, entered from the documents you publish.

The register holds a publisher, its products, its documents and their versions, and it does not care what the documents are about. What differs between the pages below is the vocabulary, the document types and the recipients — not the record underneath.

  • Fund and AIF managersUCITS and AIFMD

    Key information documents, prospectuses, reports and notices across funds, share classes and languages — at the addresses your templates and your distributors already point at.

  • Crypto-asset service providersMiCA

    White papers and their modifications, and the information a firm keeps available and current on its own website.

  • Other regulated firmsSFDR, IFR and the rest

    Disclosures published in the firm's own name — sustainability, remuneration, governance, complaints — each kept with the period it applied.

The problem

A website publishes files. A register records publications.

A CMS is built to put a file where a browser can fetch it, and it does that well. What it holds afterwards is a file name, an upload timestamp and a folder. None of those establish which document this is, which version it replaced, or the period during which it was the one in force.

So the record ends up outside the system that published it: in a spreadsheet, in an email thread, in the memory of whoever produced the document. It is usually correct. It is just not written down anywhere that can be asked a question.

This is a data model, not a failing. Publishing a key information document, a prospectus, a white paper, a remuneration disclosure or a set of performance scenarios — each of those is an event with a date, a predecessor and a period. A file system has nowhere to put any of it.

It shows up in ordinary questions. Which version was in force on 14 June 2025? What did this one replace, and when did the change take effect? Was the file for March 2026 ever published, or only produced?

The same publication, recorded two waysKID · class A · English

What the file system holds

  • kid-nordic-equity-a-2025-03.pdf
  • Uploaded 14 March 2025, 09:41, by the website user
  • Folder /wp-content/uploads/2025/03/
  • The file it replaced, if it was not overwritten

What the register records

  • Document identity: the KID for XF0000000018, in English
  • In force from 12 March 2025 until 21 April 2026
  • Supersedes the version from 28 February 2024
  • Canonical address /d/XF0000000018-kid-en, unchanged across all four versions
  • SHA-256 recorded on arrival, and an event log entry that cannot be rewritten

Both columns describe the same PDF, and the example happens to be a fund document because that is the vertical we know best. The left column is what a website can tell you about it; the right one is what a register keeps. Nothing on the left is wrong — it is simply not a record, and it cannot be queried, exported or handed to anyone who asks.

What the register holds

Attached where it belongs, addressed on its own.

A document is attached to a publisher, or to a product somewhere in that publisher's own structure — and to more than one where that is the truth of it. The attachment decides where the document is shown and how it is grouped. It does not decide the address: every document has its own, unchanged by anything that happens to the structure around it.

Each language version is a document in its own right, with its own address and its own publication date. Periodic documents are separate too: the 2023 annual report is not an earlier version of the 2024 one, and both remain current for their year.

The whole address modelThree paths
  • /d/{slug}

    The document, at the version current today

  • /d/{slug}/{date}

    One named version, reachable for good

  • /p/{publisher}

    The portal: notices first, then a table of your products and the documents each one has

The paths are the same whether documents are served from our domain or from yours by CNAME. Slugs are proposed on upload from the identifier, the document type and the language, so the address reads as what it is. Rename a document and the previous slug keeps answering — permanently, and without a redirect, because a redirect is what makes a collector record the wrong address.

Which document types a publisher has, and what they are called, is a property of the publisher and not of our model. The document library for fund and AIF managers is written out on its own page.

Evidence

What was published on 14 June 2025.

The register answers two questions, not one. Which document is current?— the canonical address, resolved now. Which document was current on a given date? — the same question asked of any day in the past.

Every version has a valid-from date. Valid-to stays open until the version is actually replaced or withdrawn. Nothing is deleted; it is superseded. Ask the register for a date and it returns the documents that were current on that date, with a manifest listing each file, its SHA-256 and its validity period, signed with our key so the recipient can verify the contents without trusting our website.

Behind it sits a hash-chained event log. Each upload, publication and supersession is written once, with the file hash, the time, the user and the hash of the preceding entry. History cannot be altered afterwards without the chain showing it.

A date in the future is never answered. Scheduled publications are visible to you and to no one else until the day they take effect.

Snapshot · XF0000000018-kid-enExample

Ask the register as at a date, and it returns the version that was current on it.

Asked as at
2025-06-14
Version returned
2025-03-12
Validity period
12 March 2025 to 21 April 2026
SHA-256
9f2c4e1b7a08d3c5b61ea479d0c8f215
Permanent address
/d/XF0000000018-kid-en/2025-03-12

Where we fit

After the document is approved. Before it is referenced.

Approved documentKilospringWebsite · Data templates · Recipients

Your process is unchanged

The document is produced, checked and approved exactly as it is today, by the same people in the same tools. We have no view on any of it and no step in it. The register begins at the point where an approved file is ready to be published.

We publish and record

The file is stored byte for byte, given its canonical address, and recorded with the date it takes effect, the version it supersedes and the period it will be in force. Publication happens at the moment you choose, not at the moment you upload.

Everyone else refers to it

Your website links to the address. The templates you deliver carry the address. A distributor, a counterparty or a data vendor collects from the address. None of them are replaced, and none of them have to be told again when a new version is published.

You do not replace your website, your document production, your administrator or your distribution arrangements. The register sits alongside them and holds the one thing none of them holds: the record of what was published, when, and in place of what. Where a publishing chain to data vendors and platforms exists, it is address-based — and a permanent address turns the submission into one made once rather than corrected each time a file is replaced.

Scope

What Kilospring does not do.

Written down because it is the part that decides how much of your organisation has to look at us before you can say yes.

  • We do not produce, calculate or translate a document

  • We do not review, check or approve what a document says

  • We do not decide whether a review is due, or when one is

  • We do not replace your website

  • We do not file or submit anything to a regulator, a distributor or a data vendor

  • We do not change a file you have uploaded, ever

The service is a technical publication service. It is not an outsourcing of anything you hold a licence for, and nothing in it requires you to delegate a regulatory judgement.

Security and data

Your documents, held plainly and kept within reach.

Files and metadata are held in storage restricted to EU jurisdiction, and we hold no personal data beyond your contact people. A file you upload is stored byte for byte and never altered, its hash recorded on arrival. Everything we hold for you — the documents, the version history and the event log — can be exported in full at any time, so leaving costs you a download rather than a negotiation.

The service is deliberately narrow, and that is what makes it easy to approve: it is a technical publication service, not an outsourcing of anything you hold a licence for. We do say mechanical things about our own storage — that the document on file is dated 12 March 2025, or that no file has been uploaded for March 2026 — as fact, never as advice.

We will appear in your register of information as an ICT third-party service provider, and the contractual terms under Article 30 of DORA apply to us however small the service is. The supplier dossier is written before the first conversation rather than after it: contractual annex, registration details, sub-processor list, place of operation within the EU, and an exit plan with a full export.

What we do
  • Receive the files you upload or forward by email

  • Give them permanent addresses

  • Keep every version, with timestamps and validity periods

  • Publish at the moment you choose

  • Show a portal per publisher, with its products and documents

What you keep
  • Ownership of every file and of the record around it

  • A full export at any time: the holding, the event log and a static mirror

  • Your addresses, served from your own domain

  • Your slugs, reserved to you and never reissued to anyone else

Getting started

We set it up, and you check it.

Onboarding is something we do rather than something we hand you. For the first customers it is roughly an hour of our time and a short conversation of yours.

  1. We import what you publish today

    You point us at the documents already on your website. We load them with the dates they carry, so the register starts with a history rather than an empty first day.

  2. Addresses are established on your domain

    One CNAME, and the addresses sit under your own host name. Slugs are proposed from the identifier, the document type and the language, and you approve them before anything is public.

  3. Existing references are updated once

    The links on your website and the addresses you have reported to anyone who collects them are changed to the canonical ones. This is the only time they change: that is the point of them.

  4. From then on you publish to the same addresses

    A new version goes to the address the old one had. The former version keeps its own dated address, and the record of the change is written as it happens.

A good first step is one product, or one set of the disclosures you publish in your own name. It is small enough to set up in an afternoon and complete enough to judge: the addresses, the version history and the answer to a date, on your own domain, with your own files.

Try it with your own documents

Start with one set, and see the record.

Tell us how you publish today and we will write back with how the register would hold your documents. If it looks right, we set up one part of what you already publish, and you look at the result before anything is referenced anywhere. Nothing to install, nothing to commit to.

You can also write to info@kilospring.com, or look through the demonstration portal first. The firm and the funds there are fictional, and each document says so in its own text.

A sentence is enough. It is the one thing we need in order to answer usefully.

We use what you write here to answer you and for nothing else: no mailing list, no profiling, and it is passed to no one. Ask us to delete it and we will, without keeping a copy.