Read-only. In writing. What your IT and legal teams ask for.

Built to pass your IT and legal review, not just your demo.

For the reviewer who needs one paragraph before deciding how much time to spend on the rest of it.

NOI Engine holds read-only credentials to your property management system and never writes to it. That scope is a contract term, not a setting. It reads your data, builds reporting and monitoring on top of it, and drafts routine communications into templates your counsel approves. Nothing resident-facing or vendor-facing is ever sent without a named person on your team approving it. Your data is never pooled, blended, benchmarked or resold across clients. There is no SOC 2 report yet, and that status is stated plainly in the legal package along with the compensating controls.

Where this document does not yet carry a specific number or a named vendor, it says so in the sentence where that answer belongs and repeats it in the register at the end. Nothing here is worded to survive a skim and fail a question.

Section 01 · the integration

Read-only, and written into the contract.

What it can do, and what it cannot. The second list is the one that matters to you, so it is the longer one.

The connection to your property management system is a dedicated read-only API user, provisioned by your team, scoped by your team, and revocable by your team in about a minute without contacting anyone here.

The platform cannot write to your system of record. Not a lease, not a charge, not a note, not a status change, not a work order. This is not a policy NOI Engine intends to keep. It is a restriction in the agreement, and the credential your IT team issues should not carry write scope in the first place. Belt and suspenders, on purpose.

If write capability is ever wanted, it is a separately signed phase with its own scope, its own sandbox testing and its own sign-off. It is not something that arrives in an update. Most operators never ask for one.

What is read: Property, unit and lease records, charges and ledgers, work orders, leasing activity, and the standard financial reports your PMS already produces. The specific endpoint and report list is not published yet, and it is yours on request rather than after a call.
Systems supported: Entrata today, through a purpose-built connector. Yardi is next on the roadmap.
Your Microsoft 365 environment: No writes. No mailbox, calendar or file access, without a separately signed phase.
Inbound access to your network: None. The platform reaches out to your PMS's API. Nothing reaches in. No agent, no workstation software, no VPN, no firewall change.

Section 02 · where the data goes

The data flow, end to end.

Four steps, in order. Every arrow points the same direction, which is the whole point of the diagram.

The scheduled pull

A scheduled job authenticates as your read-only API user and pulls the day's data.
Your isolated datastore

That data lands in your datastore. One tenant, one dataset. It is not written into a shared table with anyone else's portfolio in it.
Overnight reconciliation

Every metric is reconciled against your PMS's own reports, and every view is stamped with the timestamp it was reconciled as of. If reconciliation fails, the stamp says so rather than showing you a number nobody checked.
Views and automations

Views and automations read from that store. Nothing reads back into your PMS.

There is no return path in that diagram, and that is not an omission. The connector holds no write scope, so there is no step five.

Hosting: The platform runs on Cloudflare's network: Workers, D1 and KV. The exact product list and the data-residency answer are not published yet. Ask for the residency answer before your review opens, because it is on nearly every questionnaire and it is not a question to answer from defaults.
Retention: Your data is retained for the life of the agreement.
Deletion: On termination you get a full export first. Then the datastore is deleted and you get written confirmation that it happened, and backups age out on the same clock. The number of days is not published yet.
Backups: The retention window and the restore-testing cadence are not published yet. When they are, the second one will carry a date, because a backup nobody has restored is a hope.

Section 03 · credentials, encryption, access

How your credentials are held.

Two of the answers in this section are the ones a CISO checks first, and one of them is not written yet.

Where credentials live: Stored as encrypted secrets, never in code. Not in the repository, not in a config file, not in a spreadsheet, and not in anyone's email. They are held in the platform's secret store, injected at runtime, and not readable back out once set.
Encryption in transit: TLS on every connection, inbound and outbound. No exceptions and no plaintext fallback.
Encryption at rest: All stored data is encrypted at rest. The mechanism and the cipher are not published yet.
Who can see your dashboards: Access is gated to named email addresses on your domain that you provide and you control. Adding or removing a person is a change your team requests and it takes effect immediately. There are no shared logins, no generic accounts and no public URLs.
Single sign-on: The position on SSO is not published yet, and this page will not imply one. What is true today is the row above: access is gated to named addresses on your domain that you control. If SSO through your identity provider is a hard requirement, ask first. That answer decides whether the rest of this document is worth your afternoon.
Access on my side: Administrative access to your environment is limited to me, over multi-factor authentication, and administrative actions are logged. Whether MFA is in force on every account in the path, including the hosting account and the source repository, is not published yet.

Section 04 · what it will never do

The exclusions are contract terms, not marketing.

These are written into the agreement as an exhibit. You can read the actual language before you talk to anyone.

01

No collections dunning, and no eviction documents

Not drafted, not sent, not assembled.

Contract term

02

No handling of resident income or certification files

The platform tracks that a recertification is due and counts down to the date. It does not touch the documents.

Contract term

03

No unattended AI sends. Ever

There is no configuration, no permission level and no "trusted template" setting that lets a message reach a resident or a vendor without a named person approving it. This is not a default that can be turned off. It does not exist.

Contract term

04

No rent-pricing recommendations of any kind

The platform reports what your rents are and what your loss-to-lease is. It does not tell you what to charge, and it does not participate in anything that could be characterized as pricing coordination.

Contract term

05

No writes to your PMS or your Microsoft environment

Not without a separately signed phase, with its own scope, its own sandbox testing and its own sign-off.

Contract term

06

No pooling, blending or benchmarking of client data

Not across accounts, not for market reports, not anonymized. See data ownership and isolation.

Contract term

The exhibit is the document, not this page. Prose in a box on a website is marketing. A signed exhibit with clause numbers is a document your counsel can put in a file, and publishing the real language is the cheapest way to get through a legal review without a call. The exhibit itself is not published yet. Ask for it and you get the clause language, not a paraphrase of it.

Section 05 · ownership and isolation

Your data is yours, and it is never pooled with anyone else's.

Ask this of every multifamily software vendor you evaluate, not just this one. It should be one of your first three questions.

Your data is not aggregated with other clients' data. Not for benchmarking. Not for market reports. Not anonymized, not de-identified, not "in aggregate," and not for model improvement. One tenant, one dataset, one purpose.

Nothing in your portfolio is used to train, tune or evaluate any model, mine or a vendor's. The AI provider's own contractual commitment on the tier in use is not published yet. That one should reach you as a document from the provider, not as an assurance from me.

You own your data, your metric definitions and your configuration. You can export all of it in open formats at any time, including after the agreement ends.

After the last few years in this industry, "do you pool client data" should be one of the first three questions you ask any multifamily software vendor. Ask it of everyone, not just here.

Section 06 · AI governance and fair housing

AI never free-writes to a resident. Not once.

This is the section your counsel cares about, so it is the most specific one on the page.

Templates, not generation: Resident-facing and vendor-facing text is never composed freely by a model. The platform merges facts into templates your counsel writes and approves, using a whitelisted set of merge fields. The model's job is to select the right template and populate approved fields. It is not to decide what to say.
Your counsel owns the library: The template library belongs to your legal team. They write them, they approve them, they change them. Nothing enters the library without their sign-off, and there is no "system template" that bypasses it.
Identical treatment at every stage: Every applicant, resident and prospect at the same stage of the same process receives the same template. The platform does not vary content, tone, timing or offer by person. There is no personalization layer, because a personalization layer is exactly where disparate treatment gets in.
A named human approves every send: Every draft lands in a single approval queue. A named person on your team reads it and presses send. The approver's name, the timestamp, the template version and the final text are recorded on every message.
An immutable send log: Every send is logged and the log cannot be edited after the fact. Once a quarter your legal team gets a report of exactly what went out, under which template, approved by whom. They do not have to ask for it and they do not have to go looking. It arrives.
No protected-class inputs, and no proxies: The platform does not ingest, infer or act on any protected characteristic. The field-by-field exclusion list at the connector is not published yet. A policy is a policy. A field that is never pulled is architecture, and only the second one survives an audit, so that is the version this row will carry.
Which model, and where the text goes: The provider is not named yet. Every control above holds whichever model is used, but your counsel will still ask where resident-adjacent text is processed, and that answer belongs on this page rather than in a call.

Section 07 · reliability

If a check stops running, both of us get paged.

The failure nobody plans for in monitoring software is not a wrong number. It is a check that quietly stops running, so the alert that should have fired never fires and everything looks fine.

Heartbeat monitoring: Every scheduled job reports in. If a job does not run, or runs and fails, an alert goes to me and to your designated contact. Silence is treated as a failure, not as a pass.
Nightly reconciliation: Every metric is checked against your PMS's own reports before it is shown to anyone, and each view carries the timestamp it reconciled as of. If a figure cannot be reconciled, the view says so rather than displaying it.
A monthly reliability report: What ran, what alerted, what failed, and what did not run. Including the bad months. You should not have to take a vendor's word for uptime, and you should be suspicious of any vendor whose reliability report has never contained bad news.
Uptime commitment, RTO, RPO: Whether the agreement carries an uptime commitment, a recovery time objective or a recovery point objective is not published yet. No figure is stated here and none is implied. The three rows above are what the monitoring actually does, and the monthly report is the evidence for it.
Incident and breach notification: The notification window is not published yet. Reviewers ask for a number of hours. Its absence here is deliberate rather than an oversight, and it is one of the five items worth chasing before you sign.

Section 08 · continuity

There is one person here. Here is what that is papered with.

The honest answer to "what happens if he disappears" is a set of documents, not a reassurance. Who builds this answers the other half of that question.

Source-code escrow: The source is held by an escrow agent under release conditions you can read before signing. The agent and the triggers are not named yet. "Escrow is available" is a sales line. A named agent with named release conditions is a control, and that is what this row will carry.
Documented schemas and metric definitions: The data model and every metric definition are written down and delivered to you. Nothing is trapped in one person's head. A competent contractor can operate the platform from the documentation.
Runbooks: Every scheduled job, its dependencies, its failure modes, and what to do about each.
One-click export: Open formats, any time, including after termination.
A transition obligation: The number of days of transition assistance in the executed agreement is not published yet.
A real exit: Initial term, renewal behaviour and notice period are not published yet. When they are, they will read the same as the pricing page word for word.

The fair counterpoint: ask your funded vendors the same question. "We have forty employees" is not a continuity plan. Escrow, schemas, export and runbooks are the plan in both cases. A one-person vendor just has to hand them to you sooner.

Section 09 · legal package

What comes with the agreement.

Three of these are settled and three are open. Two of the open three are the first things a security review asks for. The third gets requested at contracting, so it can trail.

Data Processing Addendum: Executed with the master agreement.
The exclusions exhibit: Section 04, as a contract term.
Confidentiality: Covering your portfolio data, your financials and your metric definitions.
Sub-processor list: Maintained and published, with advance notice of changes. The list itself is not published yet. It will name the hosting provider, the AI provider, the notification provider and the scheduler, because a partial list is worse than none.
Insurance: Coverage is not stated yet, and none is implied anywhere on this page. Certificates are requested at contracting rather than at evaluation, so this is the one open item that can trail the others without holding you up.
Certificates and audits: There is no SOC 2 Type II report today. What is in place instead: credentials held as encrypted secrets, TLS in transit, encryption at rest, a read-only integration scope with no write endpoints, access gated to named addresses on your domain, and an immutable send log. Readiness status and expected timing are not published yet.

Section 10 · what this asks of your team

Roughly twelve hours of your people, over about three weeks.

Reviewers ask this and it almost never gets answered, so here it is before you have to ask.

One read-only API user, provisioned and scoped by your IT team. That is the entirety of the IT lift.
Two ninety-minute sessions with your accounting lead to map the chart of accounts and confirm metric definitions.
One template review with your counsel to set up and approve the initial library.
One hour of training per role.

No agent installed on anything. No software on a workstation. No changes to your network. No VPN. No inbound connection to your environment of any kind: the platform reaches out to your PMS's API, nothing reaches in.

Implementation is quoted as a fixed range at signature. The commercial terms are on the pricing page, and how this compares costs the three alternatives you are actually weighing.

The twelve hours and the three weeks above are estimates drawn from the implementation plan, not a contractual commitment. They are not yet reconciled against the pricing page, and if the two ever disagree the agreement governs.

Register · the open questions

Twenty answers this document does not carry yet.

A vendor page that answers everything has usually answered some of it by guessing, and a guess at a control is the one thing in diligence that costs more than the gap it covered. So here is the whole list, in one place, rather than worded around in the body.

The specific endpoint and report list. Categories are named in section 01. The endpoints the connector actually calls, and the reports it actually pulls, are not written down here.
Hosting products, and data residency. The provider is named in section 02. Whether every byte stays inside the United States is a separate answer and it is not on this page.
The deletion window after termination. The obligation to export first, delete, and confirm in writing is real. The number of days is not set.
Backup retention, and when a restore was last tested. Neither is stated. Both get asked for, and the second one more often than the first.
Encryption at rest: the mechanism and the cipher. "Encrypted at rest" is stated. What performs it, and with what, is not.
Single sign-on. Not answered either way. Today access is gated to named addresses on your domain that you control, which is the whole of what section 03 claims. If SSO is a requirement, raise it in your first email.
Multi-factor authentication coverage. Described on administrative access. Not stated for every account in the path.
The exclusions exhibit, as clause language. Section 04 is the plain-language version. The document your counsel would file is not published.
The AI provider's no-training commitment. That NOI Engine does not train on your data is a commitment made here. The provider's own commitment, on the tier in use, is not evidenced here.
Protected-class fields excluded at the connector, by name. The policy is stated in section 06. The enforcing architecture is not described field by field.
Which model, and where resident-adjacent text is processed. Not named. Every governance control in section 06 is independent of the answer, and the provider still has to be disclosed.
Uptime commitment, recovery time objective, recovery point objective. No figure is published and none is implied. Section 07 describes what the monitoring does instead.
The incident and breach notification window. No number of hours is committed to.
The escrow agent, and the release triggers. Neither is named.
Days of transition assistance. The obligation is described in section 08. The number is not.
Initial term, renewal behaviour, notice period. Not stated. When it is, it has to be the same sentence as the pricing page.
The sub-processor list. The commitment to maintain and publish one, with advance notice of changes, is real. The list is not written.
Technology errors and omissions, and cyber liability. No coverage is stated and none is implied.
SOC 2 readiness, and expected timing. The absence of a report is stated plainly in section 09, with the compensating controls. Where readiness stands is not.
The twelve-hour and three-week implementation figures. Estimates in section 10, not yet reconciled against the pricing page.

Every row above is an absence, not a control described loosely. Ask for any of them and the answer comes back in writing, including where the answer is "not yet." The five that most often decide a review are 06, 09, 13, 17 and 19, so those are the ones worth putting in your first email.

Send me your questionnaire.

You are going to check anyway. Better that we both spend the time once.

If your organization has a standard vendor security questionnaire, send it before the demo rather than after, and it will come back filled out. If there is a control I do not have, it will say so instead of answering around it.

There is no sales team and no gatekeeper on that email. It reaches one person, who wrote every line of this page and every line of the platform it describes.

The product itself is not behind a call either. The live demo runs on a fictional portfolio, and you can open it without talking to anyone.

If you want the fastest version of this: send the questionnaire, and add the five items flagged at the foot of the register. Those are the ones I would rather answer before your first meeting than during it.

Send the questionnaire Open the live demo

Michael Gaff

Founder and principal

Every demo is one on one, with the person who built it. Questions from your IT director or your counsel are answered in writing, including the ones where the answer is "not yet."

michael@michaelgaff.com

(317) 985-2446

Print this page for your procurement folder. The print version drops the navigation and the photography and keeps every word.

Read-only. In writing. What your IT and legal teams ask for.

Built to pass your IT and legal review, not just your demo.

Read-only, and written into the contract.

The data flow, end to end.

The scheduled pull

Your isolated datastore

Overnight reconciliation

Views and automations

How your credentials are held.

The exclusions are contract terms, not marketing.

No collections dunning, and no eviction documents

No handling of resident income or certification files

No unattended AI sends. Ever

No rent-pricing recommendations of any kind

No writes to your PMS or your Microsoft environment

No pooling, blending or benchmarking of client data

Your data is yours, and it is never pooled with anyone else's.

AI never free-writes to a resident. Not once.

If a check stops running, both of us get paged.

There is one person here. Here is what that is papered with.

What comes with the agreement.

Roughly twelve hours of your people, over about three weeks.

Twenty answers this document does not carry yet.

Send me your questionnaire.

Michael Gaff