Platform

One record. Two levels that read from it.

A transaction is written down once and read from twice: by the agent running the file, and by the brokerage responsible for it. Each level sees only its slice.

The model

Two levels, one record

A transaction is one set of facts seen from two angles. Terriv keeps a single record of those facts and shows each role what its job requires, nothing more. Every capability below carries its build state.

Level 01 · Agent

Producers running their own book. Everything an agent tracks by hand today, kept in one place.

  • Transactions An agent's active transactions are listed in deadline order, with each date pointing back at the clause it was read from.
  • Documents A filed document lands against the right transaction, and the file names what is still outstanding rather than leaving it to memory.
  • Deadlines A date becomes a tracked date when a person confirms it against the cited clause. A proposed date is not a tracked date.
  • Morning summary A daily account of what changed on the agent's own files. It summarises the record for the agent, and is not sent to anyone else.
  • Pipeline activity Lead and message activity appears from the systems the brokerage connects, under written terms.
  • Scope of view An agent sees their own transactions and clients, not another agent's business.

Level 02 · Brokerage

Broker and operations staff. The whole office in one view, ordered by what could go wrong first.

  • Office view Leadership opens one list of every active transaction instead of asking five people for a status update.
  • Workload Each agent's open files and the dates sitting on them, so load is visible before it becomes a missed deadline.
  • Exceptions Approaching deadlines, documents that are not in the file, and items with no response are raised for a person to decide on.
  • Any file A broker can open any transaction in the office and see the same record the agent sees, including the source of every date.
  • Reporting Office-level reporting across the transaction record.
  • Broker controls Which systems connect, what may be read from them, and for how long, stays with the broker. Email, calendar and transaction systems are switched on per brokerage under written terms.

The level that is not here

There is no consumer surface.

Terriv has no third level for buyers and sellers, with their own logins, their own documents and their own questions. That is a deliberate choice, not a gap.

Nothing reaches a client from Terriv. Client communication stays where it is today: with the agent and the brokerage, in the channels they already use. Terriv is not a consumer product and is not sold to buyers or sellers.

If a brokerage wants a client to know where a transaction stands, that comes from the agent, in the agent's words. Any consumer access runs through the brokerage or the agent, as a separate decision made in writing with them. It is not part of the first release and it is not on the near roadmap.

Flow

How information moves

Information enters once, is written to one record with a citation, and is read by both levels from there. Four steps, none of which runs today.

  1. Documents and communications enterContracts, disclosures and messages arrive by upload and from the systems the brokerage authorises. Nothing connects without broker approval.
  2. The record is written, with a citationTerriv reads the dates, obligations and parties out of the executed documents and files them against one transaction, with every item pointing back at the page and clause it came from.
  3. Each level reads its sliceThe agent sees their own book. The brokerage sees the whole office. Both read the same underlying record rather than two versions of it.
  4. Exceptions rise for reviewA date about to pass, a document that is not in the file, or an item with no response would be put in front of a person. Nothing is designed to be tracked until someone confirms it against the source.

Those four steps describe the intended path, not a running pipeline. Software that reads documents will sometimes miss a date or misread a clause, so a quiet list is only as complete as what the software actually caught.

What exists of this today

  • Screens The screens run on sample data and show the two views described above. Every file, name, party and date in them is fictional.
  • Demo requests The request form on the demo page posts to a real endpoint that emails us. If delivery is not configured it returns an error and says so, rather than showing a false confirmation. Built

Go deeper

What sits behind the two levels

Transaction coordination

The record itself: the executed documents, the dates written inside them, and the items still outstanding on a file. That page sets out, row by row, what Terriv does with a transaction and what it will never do.

Transaction coordination

What runs underneath

The architecture beneath the record: what would read a document, what would watch a date, what would raise an exception, and what a person still has to decide. It describes intended design rather than running software.

What runs underneath

Evaluating Terriv

See both views, end to end

A 30-minute walkthrough of both views, running on sample data. Given where the product is, most conversations should end after that call.

Written terms come before anything of yours moves, a closed file comes before a live one, and a pilot does not start until document reading actually works.