What we built next in Meridian.

This week we published the complete user guide to Meridian data rooms: the locked viewer, the quantum-signed NDA gate, multi-party rooms, the room AI, the analytics. This post was written the same day as the other half of the story: four features then in engineering, and the design rules that decide how they are built. They shipped that evening, every one with its tests in the production suite, and this page now describes live product. The guide remains the record of the product as a whole.

01Where the product stands, in one paragraph

A Meridian data room today is a private, view-only reading room. Readers pass a mandatory NDA that is signed with post-quantum ML-DSA-65 cryptography and anchored to the Armature L1 record. Documents render as watermarked pages with no download path. A room can carry four parties on tiered access that fails closed, a permission-aware assistant answers questions with citations, and every page view feeds a heat map the owner reads in the console. That is the foundation, and every feature below is built on top of it: the same document index, the same permission model, the same anchoring. Nothing gets rebuilt, and nothing gets bypassed.

02Two rules that decide how every feature is built

A data room is a trust product, and an intelligence layer is only worth adding if it inherits the trust rather than diluting it. Two rules run through everything that follows.

• A claim is only stored if its quote survives verification. Every question the room predicts, every fact it extracts, every inconsistency it flags must carry a verbatim quote from a cited page. An assertion that cannot show its source is discarded.
• Permissions fail closed, including for the new features. Everything the intelligence layer produces is stored on the owner's side of the wall. Where a reader is ever shown a generated artefact, the entitlement check runs again at the moment of reading, against that reader, and anything that cites a document outside their permission simply does not exist for them.

The intelligence layer earns its place by being checkable, not by being impressive.

03Predicted questions: the Q&A written before the first call

Every seller runs the same gauntlet. The room opens, the serious buyers read, and then the questions arrive: about the debt schedule, the customer concentration, the change-of-control clause on page forty-one. The answers exist, scattered across the documents, and the seller assembles them under time pressure, buyer by buyer, in email.

The room now does the assembly in advance. When its documents finish indexing, a room reads its own corpus, the information memorandum, the model, the contracts, the management presentation, and drafts the fifteen to twenty-five questions a sophisticated buyer is most likely to ask, grouped by theme: financial, legal and structural, commercial, operations and team, risk.

• Each question shows its work. A rationale explains why a buyer will ask it, and citations point at the passages that raise it. A question that cannot cite its trigger is not shown.
• The seller answers on their own clock. Questions arrive in a panel on the owner console, before the first buyer does. Answers are written, edited and owned by the seller; the room drafts questions, never answers.
• Publishing is deliberate, per question. An answered question can be released to the room as an FAQ entry, one at a time. A reader sees a published entry only if every document behind it is one they are entitled to read. If not, the entry is invisible to them, whole, not redacted.

04The room checks itself: cross-document consistency

The most expensive sentence in due diligence is "the model says something different from the contract." Found by a buyer, it costs credibility and price. Found by the seller first, it costs an afternoon. Rooms hold both documents; the room can do the reading.

The room reads the facts in every document, interest rates, principal amounts, valuations, dates, party names, share counts, governing law, each pinned to the page and the sentence it came from, and surfaces the places where documents genuinely disagree.

What comes out is a short list of findings, ranked by severity, each with both citations side by side: the contract page that says 7.25% and the model page that says 7.40%, one click from either. Alongside the value conflicts, the room checks for conflicting dates, party names that drift between documents ("Meridian Holdings Ltd" and "Meridian Holdings Limited" are flagged gently, conflicting roles are flagged loudly), and documents a deal of this type is expected to contain but the room does not.

• Findings are for the owner and co-administrators only. No reader sees them, no reader's assistant can surface them, and that includes the contributor whose own document raised the flag. What the owner does about a finding is a decision, and the room does not make it.
• Dismissals are remembered. A finding the owner has reviewed and dismissed stays dismissed on later scans. A tool that repeats itself gets turned off, so it is built not to.

05Signing the NDA with a wallet or a KXCO Identity

Every reader used to sign the room NDA one way: by typing their name, with the platform signing the acceptance in ML-DSA-65 and anchoring it to Armature L1. That flow stays, unchanged, and remains the default. What the gate now offers is choice: two stronger ways for a reader to bind their identity to the same undertaking.

One honest note on ergonomics: the KXCO Identity flow today is for holders of an identity keyfile, signing with the published kxco-post-quantum tooling and pasting the result. The cryptography and the evidence are complete; a one-click signer in the browser is the refinement still to come.

Three design decisions define the feature.

• A wallet signature is never the whole proof. Wallet signatures are classical cryptography, so the platform countersigns every acceptance, whatever the method, with ML-DSA-65. The wallet address strengthens who signed; the post-quantum envelope is what makes the record durable. The evidence never rests on a classical signature alone.
• Access turns on the moment the signature verifies. The reader is in and the evidence record stands behind them from that moment. Anchoring to Armature L1 follows on its own, so a brief chain outage never locks a legitimate reader out.
• One undertaking, one gate. Whichever method the reader chooses, it is the same NDA text, the same certificate emailed to both parties, the same permanent return link afterwards, and the same revocation switch for the owner.

06Deal intelligence becomes structured events

The room already knows which pages held a buyer's attention on Tuesday and how many times they came back to the financials. Today that intelligence lives in the room console, and getting it into a pipeline review means reading it there. The fourth feature turns the same facts into a stream of structured, versioned events that internal deal tooling can consume.

• Sessions, not noise. The stream does not relay every page turn. A reader's visit becomes one session summary: when they entered, which documents they read, which pages, for how long, and which visit number this was. That is the shape a pipeline can score.
• The moments that matter are events: an invitation sent or revoked, an NDA signed and by which method, a document added, a question asked of the room assistant, a session summarised.
• Deliveries are signed. Events can be pulled from an API or pushed in batches, and every delivery is signed so the receiving system can verify the sender, with an ML-DSA-65 provenance signature available alongside the standard one.
• Content stays home. Events carry names, identities and activity. Document names travel; document pages never do. The stream reports that the reader spent eleven minutes in the loan agreement, and nothing of what the loan agreement says.

This serves KXCO's own deal tooling first. The design is deliberately plain, ordered events behind a cursor, delivered by pull or by batched webhook, so that connecting anything else later is an integration, never a rebuild. Every delivery is signed twice: a shared-secret signature the receiver checks, and an ML-DSA-65 signature from the platform's own key.

07Why none of this widens access

Four new features, and the honest question is the one a security reviewer would ask: what new paths does this open into the documents? The answer is engineered to be: none.

• Generated artefacts are owner-only. Predicted questions, extracted facts and findings are never shown to a reader, and no question put to the room assistant can surface them.
• The only new reader-facing surface is the published FAQ, and it re-checks entitlement per reader at the moment of reading, failing closed exactly as document tiers do today.
• The event stream is one-way and content-free. It reports on the room; it is not a door into it.
• The signing methods add identity, never rights. A wallet or an identity credential changes how strongly a reader is bound to the NDA. It changes nothing about which documents their invitation entitles them to see.

08The post-quantum line holds

KXCO's rule for signatures has not moved since the first document was signed on the platform: the record must stay provable after quantum computers arrive. Everything in this post inherits that rule. New signing paths are either ML-DSA-65, the lattice standard NIST published as FIPS 204, from end to end, or they are classical signatures wrapped in an ML-DSA-65 countersignature so the durable evidence is post-quantum regardless. Event deliveries can carry the same provenance. The cryptography this stands on is public and independently scanned: the thirteen post-quantum packages KXCO publishes on npm and GitHub.

09The order it shipped in

The four features share a foundation but not a difficulty. They shipped in the order they could be trusted, each with its tests in the production suite before the next began.

1. Predicted questions first. It builds most directly on the indexing and assistant infrastructure already running in production, and it was valuable the day it appeared in the console.
2. The event stream second. The plumbing is deliberately simple, and its first sweep folded the room history that already existed into the stream, so it was born with months of sessions behind it.
3. The signing methods third. Signature verification is an authentication boundary, so this landed with the fullest test set of the four: replay, wrong signer, expiry, and a changed NDA text all refused before a single reader touched it.
4. The consistency check alongside. It is built to flag only genuine conflicts, and a finding the owner has dismissed stays dismissed.

The user guide remains where the product is documented as a whole, with its limits stated the way the guide states every limit: plainly.

10Questions people will ask

Are these features live today?
Yes. All four shipped on 15 August 2026: predicted questions, the consistency check, wallet and KXCO Identity NDA signing, and the events layer with signed pull and webhook delivery. Each one landed with its tests in the production suite, and this post was updated the same day to say so. The user guide remains the record of the product as a whole.

Will the room answer buyer questions on its own?
No. The room drafts the questions a buyer is likely to ask and the seller writes or approves every answer. Nothing generated is shown to a reader until the room owner publishes it, one question at a time, and unpublishing is one click.

Does wallet signing replace the typed NDA?
No. The typed name stays, unchanged and still the default. Wallet signing and KXCO Identity signing are additional ways to sign the same NDA, producing the same certificate, the same evidence record and the same Armature L1 anchor. Every path is countersigned by the platform with ML-DSA-65, so the durable record is post-quantum whichever way the reader signs.

Will readers see inconsistency findings?
No. Findings are visible only to the room owner and co-administrators. No reader and no question put to the assistant can surface them. What the owner does about a finding is the owner's decision.

Does the event feed send documents outside the room?
No. Events carry facts about activity: who entered, what was signed, which documents held attention and for how long. Document names and identities travel; page content never does. Deliveries are signed so the receiving system can verify who sent them.

This post was written when the work began and updated on 15 August 2026, the day the features shipped; it now describes live product. The product as a whole is documented in the Meridian data rooms user guide; data rooms run inside KXCO Meridian at meridian.kxco.ai, with the product overview at kxco.ai/meridian. KXCO Meridian is operated by Knightsbridge Financial Ltd, trading as KXCO. KXCO is a software company and is not a party to any transaction conducted through a data room, nor a law firm, and nothing in this post is legal advice. Cryptographic posture reflects NIST FIPS 203/204/205 alignment at Category-3 parameters; KXCO does not claim CNSA 2.0.