Eiger Vault for publishers: overview

Page intended for editors-in-chief and management.

Eiger Vault receives the content of press publishers, keeps it and seals it, then answers the questions of artificial intelligence agents with anchored answers: each sentence rests on identified articles, and each supporting article is attributed, and paid for, to the publisher it comes from. This page explains how an article reaches us, what we keep of it, and what we do and never do with it. The next three pages go into the technical detail.

1. How an article reaches us

There are two routes, which can coexist.

The push. The publisher's editorial system (CMS) sends the article to Eiger Vault itself, each time the article is published or a visible change is made to it. The publisher chooses who writes the code that pushes: a small module (a plugin) that we write and that the publisher installs in its CMS, or code that the publisher writes itself, from our deposit contract. In both cases, the publisher receives its acknowledgement only once the article has been durably recorded with us.

The fetch. Eiger Vault itself goes and reads the article at the source the publisher chooses: its website, where a feed announces new articles and each one is read at its own address, or the API of its CMS, which returns data that is already structured. The publisher has nothing to install. We read only what the publisher has admitted, we respect its robots.txt file, and we identify ourselves with a name and a contact address.

The push and the fetch are not equivalent in the trust that can be placed in them. What the publisher pushes with its key is attested by its key; what we fetch is attested by the publisher's server, of which we keep the proof of connection (see below).

Whichever route is used, an article, its images and the page as a PDF if the publisher sends it, form a single document with several parts. The structured text of the article (headline, standfirst, subheadings, paragraphs, sidebars, captions) is the part we read; the other parts are kept as they are.

2. The key that identifies each deposit

Each deposit is accompanied by a key. It alone says who is depositing: what the deposit claims about itself does not count.

• The publisher key is held by the publisher. We hand it over once only, at the time of issue, and afterwards keep only its digest and a short visible prefix. A deposit made with this key is said to be authenticated.
• The connector key is held by Eiger Vault, for the connector that reads your site. A deposit made with it is said to be attested, and is accepted only with the proof of the fetch (see below).
• An import key is used once, to deposit an archive that the publisher has handed to us and that an Eiger Vault operator has confirmed. Such a deposit is said to be delivered.

A key is tied to a single depositor, and to its sources: it allows deposits only for the sources that Eiger Vault has authorised for it. A key can be revoked at any moment; a deposit begun before the revocation runs to completion, and any later deposit is refused. The key is never put in an address: it travels only in a request header.

A source is the entity to which content is attributed: it may bring together several websites of the same publisher. Each source can have several collections, which carry the regime (paid publisher, endowment source, free source) and the default rights.

3. Sealing, versions, withdrawal

The seal. At each deposit, we compute the digest of the content, each with two independent algorithms (SHA-256 and SHA3-512), and we affix a seal that says three things: what (the digest of the declared content), who (the depositor and the identity level described above), when (the instant of receipt, read from the clock of our database). The seal is returned to the publisher in the response to the deposit. A version, its seal and its register entry are born together, in a single transaction: there is no version without a seal, and no seal without an entry.

The versions. A document is identified by the pair (source, source reference), the reference being the identifier that the CMS gives to the article. Each version of a document is immutable and numbered 1, 2, 3… A new version is created only if what the reader sees has changed: text, headline, standfirst, authors, category, displayed dates, images and captions, canonical address. Sending the same content twice creates nothing: the response returns the seal of the existing version and says so. Earlier versions remain kept for audit; the most recent one that is not withdrawn serves the answers.

Withdrawal. Eiger Vault can withdraw content from the service in two degrees. The block hides the content from all readers without destroying anything, and can be lifted; the erasure destroys the content's encryption keys and its metadata, and cannot be undone. In both cases, the identifiers, the digests and the seal remain, so that the proof of the deposit endures. These decisions are taken by Eiger Vault operators, never by a deposit: a publisher who wants to withdraw an article makes the request to us, and does not obtain it by deleting the article in its CMS. This procedure will be detailed before going into service.

4. Recovery after an interruption

A deposit is idempotent: sending it again is harmless. If the publisher has not received the acknowledgement, it sends the same request again, and receives the seal of the first deposit, without an extra version being created. We have no queue: we acknowledge only what we have durably recorded, in at least two zones of our hosting site.

Two safety nets catch what an outage may have caused to be missed. The first is a periodic redeposit of what the publisher has published recently (initially, the last 48 hours, every hour), relying on a presence check: the connector asks Eiger Vault which references it already knows, and sends only those that are missing. The second is our monitoring of the volumes received per source. An article is never lost silently, but an article never received is the only loss that cannot be recovered, which is why the redeposit is mandatory for any connector whose CMS can list its recent content.

5. What we do with the content, and what we never do with it

What we do with it.

• We keep it and seal it: the parts are kept byte for byte, encrypted, each with its own key.
• We make it searchable: the text of the article is indexed so as to find the passages that answer a question.
• We cite it with attribution: an anchored answer rests each of its sentences on identified articles, with their references, and returns to each publisher what is due to it.
• We pay for it: each supporting article is attributed to the publisher it comes from, and remunerated according to the prices and rights the publisher has set. A publisher sees each support for which it is paid: which article, which version, which passages, at what time. It never sees who asked the question.

What we never do with it.

• We do not train a generative model on publishers' content.
• We serve no part – photo, video, PDF – by default: serving it is a decision taken in view of the rights of that part.
• We do not send the full text of an article to anyone who does not hold the licence to read it: the rights (embargo, window following publication, individual and organisation licences, prices) are set by the publisher, and only the prices that the publisher has fixed are applied.
• We do not read a site whose publisher has told us no, nor what its robots.txt forbids us.
• We put in a technical trace neither the text of an article, nor its reference, nor its headline.

6. Where to read on

• For a fetch by Eiger Vault: see the technical page The fetch: what Eiger Vault reads at the publisher.
• For a publisher who writes its own plugin (push): see the technical page The push: the deposit contract, version 1, with the deposit contract, its examples and its error codes.
• To know what the plugin transmits, when, and what it never reads: see the simplified page What is transmitted?.