Every org. And the office that stewards them.

• The office

  Director and staff seats in the administration console

  Decides whether the pilot happens at all, names one staff owner for the term, and says which approvals genuinely route through Tenure instead of email. Everything else follows from those three decisions.

• Each organization in scope

  President, treasurer, and the other seats the organization actually runs on

  Does its ordinary work inside Tenure for the term: spending, events, members, documents and decisions logged where they happen rather than reconstructed afterwards.

• Incoming officers

  The same seat, held in shadow before the term begins

  Reads the seat’s record before taking it over. Read-only until the start date, then write access follows automatically, nobody hands over a password.

• Advisors attached to organizations

  Advisor tier, one capability of the sixteen in the console

  Read the limit before provisioning them. The Advisor tier’s one capability is reading the institution-wide audit log, and an institution account can currently read every organization’s budget, roster and documents, not only the ones it advises.

• Us

  Almamy Diaby and Satvik Adyanthaya

  Build the first version of the record with you, answer at one email address for the whole term, and own it when something does not work.

• A roster of organizations and seats

  Shape: A spreadsheet, an export from wherever you keep it, or an hour on a call with someone who knows it by heart.

  Who does the work: Office staff supply it. We build the seat map from it.

• Current officers and how to reach them

  Shape: Names, the seat each one holds, institutional email.

  Who does the work: Office staff supply it. Accounts are created by us in advance, against a named person, there is no self-service signup.

• Each organization’s existing drive or folder

  Shape: A folder export, a shared-drive link handed over with the organization’s agreement, or files dragged in by the officers who own them.

  Who does the work: Whoever holds it today exports it. We do the first import alongside them rather than sending instructions.

• Budget spreadsheets

  Shape: Excel or CSV, columns named however the treasurer named them, subtotal rows and all.

  Who does the work: Officers upload. The importer matches the columns and shows a preview before anything is saved.

• The office’s handbooks and policy documents

  Shape: PDF or Word.

  Who does the work: Office staff supply. They are stored and findable by title and description, file contents are not indexed, and the assistant cannot answer policy questions out of them.

• The deadline calendar the office already publishes

  Shape: The dates, and what each one is for.

  Who does the work: Office staff supply. Published once, then every organization sees it and each person is reminded once.

There is a new system to learn. It is where the work happens, or the record does not fill, and no page on this site is going to tell you otherwise. What there is not is a migration project: we do the first import from your existing drives with you, and after that the record fills as officers do the work they were already doing.

1. 01

   Decide, and write it down

   Before anything is built: the office decides whether to run this, and the scope, the organizations, the data, the support expectations and the measures below go into one document both sides sign. Nothing on this page is a substitute for that document.

2. 02

   Stand up the record together

   We build the institution, the organizations and the seat map from your roster, import the drives and budget spreadsheets with the people who own them, and load the office’s deadlines. This is the heaviest stretch for your staff, and the part we do most of.

3. 03

   Run the term in it

   Spending, events, members, documents and the approvals the office chose to route here happen in Tenure. What is not done in Tenure is not in the record, that is the mechanism, and it is also the risk.

4. 04

   Rotate

   As officers turn over, the incoming holder joins the seat in shadow before their term starts and reads it; the outgoing holder moves to alumni, keeping the record and losing the access. The handoff packet is assembled from what is there.

5. 05

   Review against the measures

   At the end of the term we go through the counts below with the office, and the office decides whether anything continues. If the numbers are bad they are still the numbers, and we bring them either way.

You would work directly with Almamy Diaby and Satvik Adyanthaya for the whole pilot. One address reaches both of us, and we answer the same day, most days , which is a description of how we work, not a service level anyone has agreed to.

The people who wrote the code are the people who answer, and what your office needs shapes what gets built next. Response times and a named escalation contact are agreed in the written scope, where they belong, rather than asserted on a web page.

• Onboarding is done with you, live. It is not handed over as documentation and a login.
• A bug goes to the same inbox as everything else, and is answered by one of the two people who will fix it.
• What the office needs during the term is what we work on during the term, ahead of our own roadmap.
• An automated suite runs against a real database on every release, so a regression is caught before it ships rather than during your term.
• Anything above that matters to you goes into the written scope, which is what the term actually runs on.

The parts an office and its security reviewer ask about first. Security carries the full control register with its sources.

• Who can read what

  Access attaches to the seat, not the person: shadow before the term, active during it, alumni after. Institution staff work through a console of sixteen capabilities across three strictly nested tiers, and the tier decides which actions are even offered.

• How approvals are decided

  Two gates across seven request types. Every step permanently records the deciding seat, what the request moved from and to, and whether a backup approver acted on another seat’s behalf. Requests show how long they have sat in a gate, flagged at three days and again at six.

• What gets written down

  Privileged actions append an audit row, and refusals are recorded alongside successes, which is what lets an office prove that something did not happen. Rows are only ever created: no update, delete or upsert against the audit table exists anywhere in the application.

• Where the record lives

  The database and the document store are encrypted at rest, and no document is served from a raw URL: every download is a signed link that expires in ten minutes.

• What leaves our infrastructure

  Tenure AI assembles its corpus under the asking person’s own permissions before anything is ranked, then sends the retrieved record text to the model provider’s API to compose the answer. the model provider is the only model subprocessor, and no records are used to train any model by us.

• Signing in

  Accounts are created by us in advance against a named person. There is no public registration and no self-service signup.

• What connects to what

  Files, decisions and documents live in Tenure itself. The one link outward is a signed calendar feed that Outlook, Google Calendar and Apple Calendar can subscribe to, showing each person only what they can already see.

• What happens at the end of the term

  The record stays, and history is not deleted by design: a seat carrying assignments, holdings or knowledge refuses deletion and is retired instead, and an outgoing officer is revoked to alumni rather than removed.

Every line below is a target, not a result. No pilot has run, nothing here has been measured, and any outcome number on this page would be invented. Each one is countable from the record itself, which means each one can fail visibly , that is the point. They would be agreed and written down before the term starts.

• Target

  Every organization in scope has a seat map that is actually populated

  Counted as: seats created and held by named people, per organization, before the first rotation. If the roster never gets built, this fails in public and early.

• Target

  Incoming officers are in the seat before their term starts

  Counted as: the share of rotating seats carrying a named shadow holder who has opened the record before the handover date.

• Target

  The approvals the office agreed to route here are decided here

  Counted as: approval decisions with a recorded deciding seat, against the volume the office expected for the term. The approvals that stayed in email are the measure of what did not work.

• Target

  Decisions do not sit

  Counted as: the share of approvals cleared before the three-day flag, using the flags the product already applies at three and six days.

• Target

  The handoff happens without anyone writing a handoff document

  Counted as: packets opened by incoming officers, and, separately, whether an outgoing officer still felt they had to write a document anyway. The second half is a conversation, not a number, and we would report it as one.

• Target

  The office would run it again

  Counted as: the office’s own written answer at the end of the term, whatever that answer is.

A measure that cannot be counted out of the record does not go on the list. If we miss one, you get the number rather than the narrative.