00 · The short version
What happened, who the reviewer was, and how to read the odd-looking labels that show up later on this page.
What we did
We took the organization architecture — the plan for how PropFlow can serve many property management companies at once without any one of them ever seeing another's data — and handed it to a different AI system with one instruction: break it.
That system ran twelve times. Each time it wrote a report: here is what is wrong, here is exactly how somebody gets hurt, here is what you must change. Each report was scored out of 10 against a bar of 9.0. Between reports, the design was rewritten to answer the findings.
The first report was a cold look at the design as it stood, with no rewrite before it. So there were twelve reports but eleven rewrites. The bar was never reached. The best score was 8.6, twice.
What the reviewer actually was
Not a person, and not the same system that wrote the design. It was an outside AI model, run in two separate modes:
- As the critic — read-only. It could open the design but change nothing. Its whole job was to write one report saying what was broken.
- As the reviser — write access to the design folder and nothing else. It took the critic's list and rewrote the design to answer it.
Every round was graded by a critic that had never seen a previous score. This matters more than it sounds. If a grader remembers that it gave 8.2 last time, the next number it writes will sit near 8.2 — not because the work is an 8.2, but because that is the number in its head. Graders anchor. So two rules kept the scores honest, and both are written into the folder's own instructions:
- A rewriter may never write a score, a grade, or a pass/fail into any file in that folder. In the instructions' own words: "A later critic must judge cold; a number it can find is a number it will anchor on."
- A critic may never read the folder holding the earlier reports. A critic that reads them is not cold.
So each score is a fresh opinion of the design as it stands that hour — not a nudge up or down from the last one.
The twelve scores
| Report | Score | Findings | What it was looking at |
|---|---|---|---|
| Report 1 | 6.1 | 17 | The design as it stood. No rewrite before it — this is the baseline. |
| Report 2 | 7.8 | 5 | After revision 1 answered all seventeen. |
| Report 3 | 8.2 | 4 | After revision 2. |
| Report 4 | 8.2 | 4 | After revision 3. |
| Report 5 | 8.2 | 3 | After revision 4. |
| Report 6 | 8.4 | 4 | After revision 5. |
| Report 7 | 8.2 | 5 | After revision 6. |
| Report 8 | 8.4 | 4 | After revision 7. |
| Report 9 | 8.3 | 4 | After revision 8. |
| Report 10 | 8.6 | 3 | After revision 9. |
| Report 11 | 8.6 | 3 | After revision 10. |
| Report 12 | 8.4 | 4 | After revision 11. Nothing has answered this one yet. |
Report 12's four findings are still open. There is no revision 12 answer — the run stopped there.
How to read the labels
Later on this page you will see things like PROP#a1. They are not code you need to write. They are just names for rows in the database, and they follow one pattern.
The whole key, once
- Everything before the slash says what the row is about — a company, a building, a phone number, a calendar.
- Everything after the slash says what kind of fact it is — the basic details, a permission, a booking, a log entry.
- The
#is only a separator inside a name. It means nothing on its own; it just keeps the parts of a name apart, the way a slash keeps a folder from a filename.
| Written | Read out loud |
|---|---|
PROP#a1 | the building called a1. PROP is short for property; a1 is its name. |
PROP#a1/META | the basic details of the building called a1. |
ORG#o/OP#requestId | for the company called o — one operation, filed under its own request number. |
CAL#resourceId/STATE | for one bookable calendar — what is currently booked on it. |
Four more turn up on this page and that is all: ORG# a customer company · ADDR# a phone number or email address the system owns · ATTACH# a row that sticks one fact onto one thing · ST-### a numbered written test case.
01 · Round by round
Eleven rewrites. For each one: what the reviewer had found, what could have gone wrong in real life if nobody had fixed it, and what was added. The score shown is the score of the report that came after the rewrite — so "6.1 → 7.8" means the rewrite was answering the 6.1 report and earned a 7.8.
A note on numbering, because it trips everyone up: revision 1 answers report 1 and is then graded as report 2. Every block below is labelled with both numbers so you never have to hold the offset in your head.
Answering the baseline — all seventeen at once
6.1 → 7.8The first report was brutal and long: seventeen findings, four of them marked critical. Two were the same shape — the system was checking which company without checking which person, or checking which person without checking which company. The rewrite added 943 lines and 47 new written test cases, and refuted none of the seventeen.
| What the reviewer found | What could have gone wrong | What was added |
|---|---|---|
| The saved list of a company's buildings could be out of date and not know it. | A building is moved to another company. The old company's saved list is refreshed, still shows the building, and looks current. Staff keep reaching a building that is no longer theirs. | The fast lookup list is demoted to a finding aid. Permission is decided against the slow, guaranteed-current record. |
| The read check asked "is this building in this company?" — never "is this person allowed in this building?" | An employee is given access to exactly one building. Because the company runs twelve, a direct read of any of the other eleven passes the check. | One single permission test that every read and every write must pass: this person, this company, this action, this thing, this view, right now. |
| Moving a phone number had no lock on the rules hanging under it. | While a number is being moved to a new company, someone adds a maintenance rule underneath it. The move finishes; the rule survives, pointing at the old company. The number keeps behaving for a company that no longer holds it. | Each phone number gets a version stamp. Every change under it must bump that stamp in the same instant, or be refused. |
| An acquisition changed a building's company by editing one field. | The building says "company B" while its people, conversations and logins are still filed under company A. An old permission slip that names the building still opens it. | A building's home never changes. An acquisition creates a new building record and freezes the old one, with a named step-by-step handover. |
| The "one and only one" rule was enforced with a timestamp. | Two people set the main phone number at the same moment. Each writes a row stamped with a different millisecond, so neither collides. The building now has two main numbers. | A fixed placeholder row per slot that both writers must fight over, so exactly one wins. |
| Groups of buildings can overlap, and locking a rule for one group had no safe answer. | Building P is in groups G and H; building Q is only in H. Locking a fee for G either wipes H's fee — changing Q, which has nothing to do with G — or leaves a live rule that the lock is supposed to have covered. | Locks stop travelling down a family tree. Each lock names exactly the buildings it binds, and a shared rule used elsewhere survives. |
| A shortcut lookup returned an answer before the safety checks ran. | A locked company-wide greeting is quietly overridden by a phone-line greeting, and the system reports back that nothing was locked. | Every candidate answer, however it was found, goes through one checking pipeline before it can be returned. |
| Calendar holds were written against the connection, not the calendar. | Two different connections point at the same calendar. Two people are each confirmed for the same 10:00 tour with the same person. | One identity for the thing actually being consumed — a person's time, a room — held for the whole block, including the travel gaps left either side of it. |
| Old rows were kept, but nothing said how to read "what was true last month." | An owner asks why a fee was quoted in October. Nobody can answer, because the groups and defaults have moved since. | Every consequential decision stores its own evidence at the moment it is made: the inputs, the rules used, the permission, the time. |
| A delegated permission named the company that granted it, not the specific agreement. | An old management agreement ends and a new one with the same company begins. The tidy-up of the old one strips the access granted under the new one. | Every permission names the exact agreement, its version, who issued it, what it covers, and when it expires. |
| An owner report was checked against today's owner, not the period it covers. | A buyer takes over on 15 October. The October report, sent on the 31st, contains 1–14 October — two weeks of the seller's business handed to the buyer. | Permission is granted per source, per field and per date range, and it is stored with the report. |
| The change log could lose entries, and "undo" replayed old storage instead of re-checking. | Two edits to the same value overwrite each other in the log, so one is invisible. An "undo" restores a value that a lock has since forbidden. | Every change gets its own unique log number. Undo becomes a fresh command that must pass today's permission checks. |
| The vendor fallback ignored the consent rule the earlier step honoured. | A building has explicitly refused the shared vendor list. The list is correctly skipped — and the very next fallback step picks the same plumber and dispatches him anyway. | One eligible-vendor set, built once with consent inside it. Every preference and fallback path picks only from that set. |
| A yes/no answer was itself another company's private fact. | Someone types email addresses into an invite box and learns which of them already exist on the platform — that is, which of their competitors are our customers. Separately, a phone number given to us in confidence gets copied into a field marked public. | Invitations stop answering that question. Imported contact details stay private until somebody with the right to publish them says so. |
| The "only one worker may refresh this login" ticket did not protect its replacement. | Worker A stalls. Its ticket expires and worker B takes over. A wakes up, overwrites the login and deletes B's ticket. The stored login no longer matches what the outside service holds — the calendar or mailbox company we connect to — and the connection breaks. | The ticket carries an owner stamp; only its current owner may finish or release it, and an uncertain outcome must be reconciled, never blindly retried. |
| Merging two vendor records merged the contracts attached to them. | One customer has two contracts with what turns out to be the same vendor, with different coverage and different permissions. The merge quietly gives the vendor the union of both. | Merging is frozen until an explicit collision plan exists, and it can never widen permissions on its own. |
| One setting was written one way and read another. | A manager saves a preferred-plumber list. The lookup never loads it, and every job quietly falls through to a default. | One agreed storage shape, used by every writer, every reader, and every migration — every job that moves old data into a new shape. The competing spelling is refused. |
Who received it, and who is still allowed to act
7.8 → 8.2With the obvious holes closed, the reviewer went after the edges of arrival and departure — messages that show up late, people who leave, calendars that belong to a human rather than to a company.
| What the reviewer found | What could have gone wrong | What was added |
|---|---|---|
| A first message with no prior record was filed against whoever holds the number now. | A private text arrives at a number while company A holds it. The notification to us fails. The number is released and reassigned to company B. The notification finally lands — and company B gets a conversation containing company A's resident's message. This was marked critical. | A first message must prove which company held the number at the time, and which route inside it actually took the message. Messages that cannot prove it are quarantined — set aside where they cannot act — rather than guessed at. |
| Access granted "as a representative of company B" had no live link to still representing company B. | A management company gives one of its staff access to a client's buildings. The management company later removes that person. Their login still works for other legitimate work, and their access to the client's buildings is never re-checked. | Company-derived access now carries a live eligibility reference. Losing the qualification revokes the access on the spot. |
| A calendar identifies a diary, not the human whose time is being spent. | One leasing agent has a calendar in company A and a different calendar in company B. Two tours are booked for the same hour. Both succeed. The agent is in two places at once. | The person becomes the thing being reserved. Calendars are how we look and where we write, not what we consume. |
| A street address was being used as a building's identity. | Apartments and ground-floor retail at the same address arrive from two different accounts. The import quietly merges them into one property, so their settings, histories and permissions now all point at the same record. | Buildings get their own stable identity. The address becomes a hint for matching, never the key. An ambiguous match waits for a human decision. |
| Narrowing what a past recipient may still read had nowhere to be recorded. | A report was legitimately published. A later, properly authorized decision narrows what that recipient may keep reading. The old report still carries its original, wider permission, so the recipient keeps reading everything. | A current restriction record sits beside the original permission. Every read is the overlap of the original grant, the current restriction and today's permission. |
Old messages, old links, and a hidden size ceiling
8.2 → 8.2| What the reviewer found | What could have gone wrong | What was added |
|---|---|---|
| Changing which building a conversation is "about" also changed who could read its older messages. | A resident discusses building P on a shared line. Later, the thread gets pointed at building Q. Q's staff — a different management team inside the same company — can now read P's earlier messages, photos and summaries. | Every message carries its own permanent scope, fixed when it was received. Re-pointing a thread affects only what comes next. |
| A link to a photo kept working after the person's access was taken away. | A manager grabs a photo link while authorized. Their access is revoked. They open the link — or forward it — and it still works, because the link is a key in its own right. | All protected files go through one gate that re-checks permission at the moment of download, on every piece of the file as it arrives. The old direct paths are retired as part of the switch-over, not "later". |
| One arriving email that reaches two mailboxes could only be recorded once. | An email is legitimately delivered to two of a company's mailboxes. Recording it against the first leaves the second with no record at all — so its reply route, its recovery and its history simply do not exist. | One record for the arriving message, and a separate receipt per recipient, each independently provable. |
| A hidden ceiling on company size. | A company's complete configuration map covers 100 separately-held addresses, each of which has to be checked on its own. That is 102 things to check at once, and the database will only do 100 in one all-or-nothing group. Each individual setting is accepted, and the whole-map operation becomes permanently impossible — not slow. Retrying never helps. | The design now states which sizes it supports, which checks can be covered by a cheaper guarantee, and where a big job must be paged instead. |
What the AI is allowed to repeat, and where a fact lives
8.2 → 8.2| What the reviewer found | What could have gone wrong | What was added |
|---|---|---|
| Text written by the model did not carry its sources' restrictions. | A staff member may read the internal discussion of a resident's dispute, and may send that resident ordinary messages. The model reads the internal notes and writes a resident-facing message containing them. Both permissions pass; the building is the same on every side; nothing refuses. The resident receives the internal discussion. | Generated output inherits every restriction of every input — including inputs the model does not quote — and is authorized against each actual recipient before it goes out. |
| The same fact was stored in two different places. | A building's status reads "active" in one row and "transferred" in another, and both rows are perfectly valid at the same instant. One part of the system retires the building; another keeps operating it. | One named home per fact, one named writer. Any copy must be strictly derived, with no writer of its own. |
| A legitimate building-level override was read as a contradiction. | The company sets a pet fee. One building lawfully sets a different one. Because the two overlap, the system calls it a conflict and refuses to answer at all — so a building that did nothing wrong cannot quote a fee. | Conflict is redefined by authority position: an ordered default and an override are not a conflict; two claims at the same level are. |
| "Message delivered" did not mean the follow-up record was written. | A message is sent and settled. The note it was supposed to write back into the property system is still pending. The connection is then revoked. Nothing knows whether that note is unstarted work needing fresh permission, or in-flight work that must be waited on. | Every outside effect gets its own permission point, its own counter and its own receipt. Finishing one never discharges another. |
Two companies in one storage address, and consent coming back from the dead
8.2 → 8.4| What the reviewer found | What could have gone wrong | What was added |
|---|---|---|
| Work-order sub-records had no company stamp of their own. | Two customers import work order number 604 from two different accounts in the same millisecond. The identity built for each one uses only the provider, the external number and the clock — so both land at the same storage address. Their private timelines and quotes go into one shared bucket. This was marked critical, and the reviewer reproduced it against the real code that builds the identity. | Every private storage address must resolve to exactly one company anchor. A permission check on the parent cannot rescue an ambiguous child. |
| Saying START to one company revived another company's old permission. | A resident consents to company A, then to company B, then texts STOP. Later they text START to company A. Company B's old, correctly-stamped consent is still on file and nothing says it died with the STOP — so company B starts messaging again, having never been re-invited. | A stop marker with a counter that only goes up. Consents record the counter they were issued under; anything older than the last stop is dead. |
| An ordinary staff calendar could never reach "confirmed". | A leasing employee connects their own calendar and keeps using it. We reserve the person, create the event, get the receipt, and the host accepts — and the rule still refuses to say "confirmed", because the employee can also edit that calendar themselves. Safe, but it means the most common arrangement in the business is unsupported. | Two different promises, written down separately: exclusive control where we have it, and acknowledged-event booking with a defined recovery path where we do not. |
Recycled phone numbers, duplicate logins, and a clock that stopped
8.4 → 8.2| What the reviewer found | What could have gone wrong | What was added |
|---|---|---|
| Consent stayed attached to the number, not the person. | A person consents at their number. The number later belongs to somebody else, and the records are updated to say so. The new person verifies the number but never consents. Every check passes, using the previous person's permission, and we message a stranger. | Consent is tied to the exact person and the exact stretch of time they held that number. |
| Two records could hold the same login. | A migration, or two separate connection paths, create two entries for one login. Each has its own "only one worker at a time" ticket, so they never collide — and both refresh the same login. With an outside service that rotates logins, that can invalidate the live one and force a reconnect. | One agreed way to recognize that two entries are the same authorization, so they share one referee. |
| Swapping the host on a booking deadlocked against its own held room. | A tour holds agent H1 and room R from 10:00. H1 falls ill. Assigning H2 needs the room — which the booking itself is still holding. Releasing the room first opens exactly the gap the rules forbid. | A replacement is one step that counts what the old and new versions have in common only once, and keeps unsettled obligations attached. |
| An expiring permission could be checked against a time that had already passed. | A delegated policy change passes its check a moment before the permission expires. The work pauses. It resumes after expiry and commits, because the comparison is still against the earlier captured time. The database has no way to say "and check the clock right now." | An explicit, enforceable moment of admission, plus re-checks after the fact for reads that follow. |
Restoring a backup, removing a person, pausing one topic
8.2 → 8.4| What the reviewer found | What could have gone wrong | What was added |
|---|---|---|
| Restoring a backup restored revoked access. | A backup is taken. Then someone's access is revoked, a recipient's rights are narrowed, and a pending command is used up. The backup is restored. Everything inside it agrees with everything else inside it — so the revoked reader qualifies again and the used-up command looks unused. This was marked critical. | A restored copy starts closed. Something outside the restored data decides when it may open, and current restrictions have to be reconciled first. |
| Removing someone from one company's team deleted their login outright. | A person works for company A as ordinary staff and is the only administrator of company B. Company A removes them. The existing removal path signs them out everywhere and deletes their profile — so company B is left with no administrator at all. | Removing someone from a company closes that company's membership only. Disabling a login globally is a different power, with its own permission and its own handling for orphaned administrators. |
| "Pause renewal messages, keep maintenance" had nowhere to live. | A resident asks to stop hearing about their renewal but keep hearing about repairs. There is no record that says so — only a full stop, or nothing. Queued renewal messages go out anyway. | One authoritative pause record, scoped to a topic, that beats any broader permission while leaving unrelated messages alone. |
| Ordinary texting had no positive way to prove which route received a message. | A number's routing changes. A message received before the change arrives late, and an ordinary new one arrives after. The available information identifies the sender, the recipient and the account — but not which of our routes originally took it. Safe refusal was defined; the normal accepting path was not. | A per-message service identity that supplies the proof. A routing change requires a new service identity. |
| One person with two calendars had no shape at all. | A staff member has two calendars that must both block their availability, with one chosen for writing events. The record had room for exactly one. | Calendars keyed individually on the same person record, plus a separate guarded choice of which one receives events. |
Late messages, competing calendars, and tours you cannot drive between
8.4 → 8.3| What the reviewer found | What could have gone wrong | What was added |
|---|---|---|
| A late first message got filed against whichever building is answerable now. | A company-wide number serves only building P. A first message arrives at the provider, but the notification to us is delayed. Meanwhile P is retired and Q becomes the only answerable building. The delayed message passes every check and gets pinned to Q — so Q's staff read content meant for P. | Evidence of the original building is required before a first message can be pinned. Without it the message stays unassigned and restricted. |
| Person's calendar versus building's calendar — no rule said which wins. | An agent's own calendar says X, the building says Y, and the tour says "inherit". Both are valid, writable and watched. Nothing decides where the appointment goes. | The full order of precedence written out — person, explicit assignment, building, groups, company, fallback — with what happens when a choice is disabled or unavailable. |
| Back-to-back tours can be legal and still impossible. | One agent has two tours at properties far apart. The gap is longer than the padding the system leaves between appointments, so nothing overlaps and both bookings are accepted — but nobody can drive it. The prospect waits at an empty building. | Travel evidence attached to the reservation, checked against both the tour before and the tour after, on booking, on reassignment and on any change of location. |
| Moving a company to a different billing account moved no seat count. | Two companies each sit inside their seat limit on separate accounts. One moves onto the other's account. The combined staff exceeds the cap — and because nobody is being newly activated, the check that counts seats never runs. | One command that moves the exact staff list and enforces the destination's cap in the same step. |
Permission by side door, live speech, and two kinds of deadlock
8.3 → 8.6| What the reviewer found | What could have gone wrong | What was added |
|---|---|---|
| Adding a building to a group silently widened somebody's permission. | A staff member can read conversations for group G. An administrator who is allowed to organize buildings — but not to read or delegate building Q's conversations — adds Q to G. No permission was issued, no value changed, and the staff member can now read Q's conversations. | Permissions carry a fixed ceiling that group membership cannot exceed. Changing membership must be authorized for every permission it would widen. |
| Live voice had no place to stop a sentence. | A call is under way with private context loaded. The caller's access is revoked, or the call moves to a narrower topic. The system speaks another sentence without touching any tool — and every check we have lives on tools and database reads, so nothing can stop it. | A defined checkpoint before speech: a bounded unit of audio, a source list, a current permission check, a context reset, and a rule for audio already recorded but not yet spoken. |
| One shared recovery counter made every customer wait on every other. | One busy customer's backlog constantly writes to a single shared counter. An unrelated customer's ordinary reads — and their own urgent revocations — queue behind it, with nothing about them having changed. | Separate, independently numbered recovery areas, plus reserved capacity for the commands that take permissions away. |
| Replacing a lone administrator on a full account was impossible. | One billing account covers twelve customers, each with a single administrator, and it is at its seat cap. One administrator leaves. Adding the replacement first breaks the cap; removing the leaver first breaks the "never leave a company without an administrator" rule. Both the start and the end state are legal; there is no legal path between them. | One handover command that publishes the incoming person, the outgoing closure and the seat count together, and validates the rules against the finished state rather than each step. |
Promising more than the calendar shows, and an export that never finishes
8.6 → 8.6This is the round that also swept up an independent second opinion — a separate reviewer, run from a different starting point on the evening of 8 September, whose verdict was that the design stood: not one of its eleven cases needed a different model. Those eleven were folded in and answered here, along with a twelfth item it had raised separately — the "2FA reminder cadence" gap described in 03 · Three moments.
| What the reviewer found | What could have gone wrong | What was added |
|---|---|---|
| Calendar promises exceeded what a busy-only connection can actually show. | Someone grants us "busy or free" access and nothing more. We promise to notice if a booked appointment is deleted — but a deleted booking replaced by an unrelated appointment at exactly the same hour looks identical from the outside. We also promise travel-time routing, which needs locations we were never given. So an ordinary lunch block with no location can make a perfectly reachable tour look impossible. | Three separate named service levels, each with the permissions it needs and the promise it can honestly make. Nothing quietly downgrades. |
| A shared phone number sitting on a tag could not be chosen as the sender for either building. | Two buildings share one number, held on a label that groups them. A prospect fills in a web form for the first building. There is no earlier conversation to reply into, and the shared number is not on the path the system walks — so the confirmation cannot be sent from the number the prospect would recognize. Put a building in two such labels and there are two valid numbers and no rule to pick. | An explicit recorded choice of sending number per building, per channel, per purpose, with named refusals when it is missing or invalid. |
| A long export could never finish while ordinary messages kept arriving. | An authorized export of conversation history needs several pages. Between page one and page two, one ordinary message arrives. That moves the underlying list, so the export is invalidated and must restart — and the same thing happens again. On a busy account the export can never complete, no matter how many times it is retried. | An export that pins an exact cut-off and keeps those exact versions for its lifetime, while still re-checking permission on every page — so new messages no longer reset it, but a revoked permission still stops it. |
The last one: safety during recovery, voice, and a founder's ruling
8.6 → 8.4The final rewrite answered three findings and, in the same pass, absorbed the founders' newest direction — one managing firm per property, with that firm deciding which rules a building may override. It was the biggest single round: thirteen documents, 770 lines added, 36 new test cases.
| What the reviewer found | What could have gone wrong | What was added |
|---|---|---|
| A STOP arriving during recovery was refused with no record of the refusal. | The system is closing its books to recover. A resident texts STOP; the message is refused and the provider is told to try again later. The books close, the system reopens, and a message goes out to that resident — then the retried STOP arrives. | Refusals to accept restrictive messages are now recorded durably and survive the closing of the books. Reopening the ability to send is a separate step that must prove those pending refusals have been settled. |
| Voice had no way to prove which route originally received a call. | A call reaches a number just before its routing changes, and the first notification arrives afterwards. The current routing, the caller's number and a valid signature — the stamp proving the notification really came from the phone company — together still cannot prove which of our routes actually took the call — so the safe answer is to refuse, and the ordinary voice path stays blocked. | One provider-side receiving account permanently bound to one number and route, with the authenticated identity that created it as the proof. Going from one route to another and back uses three distinct records, never two. |
| An unproven login could freeze an unrelated customer's working one. | A login is serving customer B perfectly well. Customer A adds another authorization that cannot be proven either identical or independent. To be safe, the system draws the boundary wide — and B's refreshes stop, through no fault of B's, with no stated route back. | Only a proven match shares a referee. An unproven candidate is quarantined on its own and cannot acquire the power to freeze anything. |
02 · Why the scores went flat
This is the single most misread thing about the series. The scores sat between 8.2 and 8.6 for nine straight reports. That is not the design failing to improve. It is the reviewer running out of surface at one level and dropping to the next.
The proof is that the topics never repeat
If the design were stuck, the same findings would keep coming back. They never do. Here is the whole run, one line each. Read down the right-hand column: nothing on it is a re-run of the line above.
| Report | Score | What it was about |
|---|---|---|
| 1 | 6.1 | The basics: caching, the read check, moving a phone number, changing hands, uniqueness, locks, the lookup, calendars, history, delegation, reports, the audit log, vendor fallback, privacy, logins, merging, storage spelling. |
| 2 | 7.8 | Arrival and departure: who received a late message, whether a person still represents their employer, whose time a calendar spends, whether an address is an identity, narrowing what a past recipient may read. |
| 3 | 8.2 | Content and scale: which messages a re-pointed thread exposes, whether a file link outlives permission, one email to two mailboxes, a hidden ceiling on company size. |
| 4 | 8.2 | What the model may repeat, where a fact lives, whether an override is a conflict, whether "delivered" means "written back". |
| 5 | 8.2 | Storage addresses shared between customers, consent coming back after a stop, an ordinary calendar that can never reach "confirmed". |
| 6 | 8.4 | Recycled numbers, duplicate logins, replacing a host on a booking, a permission expiring mid-write. |
| 7 | 8.2 | Restoring a backup, removing a person from one company versus everywhere, pausing one topic, proving which route received a text, two calendars on one person. |
| 8 | 8.4 | Late first messages pinned to the wrong building, competing calendar choices, tours nobody can drive between, moving between billing accounts. |
| 9 | 8.3 | Permission widened by a side door, live speech with no checkpoint, one shared counter starving everyone, an administrator handover with no legal path. |
| 10 | 8.6 | Promising more than a busy-only calendar shows, choosing a shared number as the sender, an export that can never finish. |
| 11 | 8.6 | Restrictive messages refused during recovery, proving which route received a call, an unproven login freezing a working one. |
| 12 | 8.4 | Unauthenticated input blocking a stranger's messages, one firm per building versus per managed scope, a size ceiling coming back through the new firm rules, two big operations deadlocking. |
Some subjects come back — calendars appear in reports 1, 2, 5, 8 and 10; logins in 1, 6 and 11 — but never as the same defect. Calendars go: the hold is on the wrong object (1) → the calendar is not the person (2) → an ordinary staff calendar can never be confirmed (5) → nothing says which of two calendars wins (8) → we promise more than a busy-only connection can show (10). That is a staircase, not a loop.
What report 11 said, exactly
Report 11 opened by handing back the questions report 10 had raised about deterministic ordering — the ones about overlapping groups, choosing a calendar and choosing an outbound sender:
"The governing resolver rules specify deterministic ordering for the overlapping-group, calendar-selection, and outbound-selection cases I checked. The remaining blockers concern executable protocols at security boundaries."
Report 11, opening paragraph
Then it raised three entirely different blockers — recovery, voice attribution, credentials. Report 12 did the same thing: it opened by crediting "deterministic resolution, explicit grant lineage, immutable custody, and substantial recovery contracts," then raised four new topics. That is the shape of the whole run.
One honest correction. Report 11 does not use the words "all three of report 10's blockers are closed." It names the ordering questions it re-checked and found settled, and it does not return to report 10's export finding at all. The claim on this page is the narrower, sourced one.
The dip at the end is not a regression either
Report 12 scored 8.4, below report 11's 8.6. But three of its four findings are about rules that were added or completed in revision 11 — the new one-managing-firm structure and the security protocols finished alongside it. The reviewer is grading brand-new surface area, not re-grading old ground. A design that grows a new mechanism and immediately gets it stress-tested is behaving correctly.
One process note that explains why report 11 looks different from the ones before it: after report 10, the run stopped itself — "reached round 10 below 9.0 — stopping without manufacturing a pass." It was restarted about three hours later with the independent second opinion folded into the work.
03 · Three moments worth knowing about
Three things happened during the run that say more about how this kind of review works than any score does.
1. A setting the founders had named out loud had no home for ten rounds
On 8 September, in the founders' own standup, the question came up directly:
"…the setting changes, and it's very detailed, like the 2 factor, authentication reminder cadence like, where is that going to live? And who has control of it?"
The founders' standup, 8 September
"Two-factor authentication" is the second step when you log in — the code from your phone. "Reminder cadence" is how often we nag someone who has not set it up. It is not an exotic feature. It was named by a founder, by name, in a meeting, as an example of exactly the kind of thing the architecture is supposed to have a place for.
Why it is worth knowing. Adversarial review is very good at finding ways a written rule can be abused. It is much worse at noticing that a rule is missing — and even once it is noticed, a finding that says "this thing does not exist" does not force itself into the next round the way "this thing can be exploited" does. Those are two different jobs needing two different instruments, which is exactly the argument for having run a second, independent reviewer alongside the graded one.
The independent reviewer also named the reason it was easy to miss: a two-factor reminder is a property of an account, not of a building — so it falls in the seam between the architecture work and the settings work, and was empty on both sides.
2. The reviewer argued with a founder's ruling from the same day — and won
On 9 September at 11:11 in the morning, the founder made a ruling and said he was about to start building on it:
"I'll make it the rule then that there's strictly just one property management firm behind a new property. And then that firm will determine who takes precedence, whether it's themselves or if the property has like a specific nuanced policy. So the firm should be able to kind of delegate those rules."
The founder, 9 September, 11:11 — recorded in the decision file as D-0909-4
He added that unlike the other rulings that day he was confident in this one — "just making sure before like I start executing" — which the design folder's own notes read as an invitation to argue rather than a closed door. The design was rewritten to implement it.
Later that same afternoon, report 12 argued back. Its second finding said the rule had been written onto the wrong thing:
- The rule was attached to the physical building.
- But the design already allows two genuinely separate properties inside one building — apartments upstairs, retail on the ground floor.
- So a mixed-use building with a residential firm and a retail firm would be refused, because the building may only have one firm. And transferring just the residential half would force retiring the retail half too.
- The obvious workaround — call the same structure two buildings — is worse: that corrupts what a building means.
The reviewer's recommendation was to keep the founder's one-firm rule, but bind it to the managed scope rather than the physical structure — and it explicitly flagged this as a decision only a human could make: if the intent really is one firm per physical building, that is a material product restriction and it should be stated out loud before anyone builds on it.
The design's own notes then did something worth copying: they immediately named the hole in the new answer. Mixed-use routinely shares one street address, so "separate records have separate addresses" stops telling them apart, and somebody will write "100 Main St (retail)" — which is the identity corruption the reviewer warned about, walking back in through the front door. The proposed fix is that the real distinguisher is the management scope, with the address as the label humans read.
3. The round that tried to tidy up, and destroyed 3,047 lines
The very first rewrite went wrong. Asked to answer seventeen findings, it decided to condense the design — folding pages of written plan into terse rules. The numbers, from the run log:
It was caught before the automatic chain could commit it and hand it to the next reviewer. The reason it mattered is not sentiment about words. It is that the canonical record is the document the founders read, and other pages link to it by line number. Condensing it breaks every one of those links, silently, and replaces the plan a human agreed to with a summary nobody agreed to.
The rejected attempt was not simply binned. Later rounds were pointed at it deliberately, told to reuse the good rules it had invented and to reuse none of its deletions.
04 · What is still open
Everything below is genuinely unfinished. This list is built only from the last report and the last rewrite — earlier lists have been superseded, and carrying them forward would make the design look worse than it is.
The four findings nobody has answered yet
Report 12 was the last one. There is no revision after it, so all four of these are open as written.
- Anyone can silently block messages to a stranger. High Someone sends a properly-shaped "STOP" naming a phone number that is not theirs, with an invalid signature. Before rejecting it, the system already changed that number's shared hold — so legitimate messages to that person, including from a completely different customer, now refuse. Repeat it and you can keep interrupting a stranger's messages without controlling their phone or holding any permission at all. The fix named: prove who is asking before touching a shared hold.
- The one-firm rule is bolted to buildings, not to managed scopes. High The same objection the founder agreed with, described in 03 · Three moments. The founder has since drawn the new line, and the notes list what still has to move to implement it — the firm and its appointment come off the building and onto the management scope, and everything that currently hangs off the building and follows from the firm has to be re-sited or explicitly left where it is.
- The size ceiling came back through the new firm rules. High A regional policy covering 100 buildings now has to check each building's management appointment before it can be changed — 102 things at once, against a database that will only do 100 in one all-or-nothing group. This is the same shape as the ceiling found in report 3, re-entering through the rules written last round. It is safely refused rather than done wrong, but that means shared regional policy is unsupported at that size.
- Two large clean-up operations can deadlock each other. Medium Two authorized, oversized staff-retirement runs touch overlapping customers. One locks customer A then asks for B; the other locks B then asks for A. Both are healthy, both are legitimate, and nothing says which one has to back off. The locks survive crashes and block ordinary access while they stand.
Questions only the founders can answer
These are not engineering gaps. The design refuses to guess them, and the operations that depend on them stay switched off until they are answered.
| The question | Why it is blocking |
|---|---|
| How a security deposit is expressed, and on what basis | The engineering is designed and written down — fixed amounts, multiples of rent, per-contract formulas, with the exact operands, currency and rounding. But the setting stays inactive and refuses writes until the representation and the legal basis are chosen. No number was invented. |
| Which workflow the newest signed partner gets first | They asked for renewals first; the committed first product lane is leasing. The two conflict, and the schedule and resourcing have to be re-priced either way. The data-separation work comes before either one, by ruling — the open choice cannot waive it. |
| Who certifies that a person represents a management company | Access granted "as a representative" now depends on live proof of that qualification. Nobody has said who issues it, so grants built on that basis cannot be switched on. |
| What history an incoming or outgoing owner or manager may see, keep and have corrected | The mechanism exists and is enforced per source, per field and per date range. The terms themselves are a business decision, and reads without them refuse. |
| Which vendor facts may go into a shared directory, and who may publish them | Imported vendor details stay private until someone with the right to publish says otherwise. Until that right is defined, nothing is published. |
| What "confirmed" promises a customer for a booking | Three service levels are now written out with the permissions each needs. Which one we actually sell — and the travel-time assurance that goes with it — is a commercial decision. |
Two unanswered questions inside the new firm rules
The founder's newest ruling created two cases the notes flag as open and answered by nobody: when one building is split between two firms, do they share the building's phone number (it is a building-level attachment today), and whose quiet hours reach a resident who can hear both?
The largest caveat of all
05 · Where this came from
Everything on this page traces to three sources. Nothing was inferred, and where the brief for this page was stronger than the source, the source won.
The sources
| Source | What was taken from it |
|---|---|
CHANGELOG-astra.md856 lines, eleven entries | What each rewrite changed and why; the second-order cases checked; the human decisions still owed; the verification each round ran. |
| The twelve reviewer reports | The scores, the findings, the failure scenarios, and the exact opening sentences quoted in 02. |
| The run log | Timings, per-round sizes, the rejected first attempt, the stop after report 10 and the restart. |
| The design set | The label pattern in 00; the founders' decision file; the working rules the reviewer and rewriter were held to. |
| The founders' standup transcript, 8 September | The quoted question about the two-factor reminder cadence. |
Three places this page is deliberately weaker than it could have been
- Report 11 and report 10's blockers. Report 11 confirms the ordering questions — overlapping groups, calendar choice, outbound sender choice — and says the remaining blockers are somewhere else entirely. It does not mention the export finding. So this page claims the narrower thing the report actually says, not "all three closed."
- The three core ideas. No source names "three core ideas" in those words. The load-bearing ideas quoted in 00 are the ones report 12 itself credits the design with — one answer from every lookup, every permission traceable to the permission that granted it, and a building that never quietly changes hands. That framing is the last reviewer's, not this page's.
- Timings. "Hours later" is given as clock times where the sources record them, and as "roughly" where they record a range.
Two things worth knowing if you go to the source
- The change log is not in date order. Reading it top to bottom gives you revision 10, then revisions 1 through 9, then revision 11. Match an entry to its round by the test-case numbers it adds, not by its position or its date.
- "Revision N" on this page means the Nth rewrite, and it answers report N and is graded as report N+1. The source files use a different offset, because the first report needed no rewrite before it.
What was left out
Two kinds of thing were dropped rather than paraphrased. Real customer names appear in the first report's examples; they are written here as "one company" and "another company" instead. Vendor and product names appear throughout the sources as evidence; they are written here as "the database", "the provider", "the phone company". Neither changes any claim.