What our database actually refused
We had written that the evidence in our property operations system could not be changed. On Friday, we tested that claim directly against the database. It allowed an ordinary signed-in user to change it.
That is a useful place to begin the first letter. We run a property company in Sweden, and we build, test and introduce AI and automation into its daily work. Some experiments become systems we rely on. Others give us a better question to ask of the software we already use. The Journal records what we learn; this letter brings the work together with developments from the field that matter to someone who runs buildings.
If you found us through one of the first pieces, welcome. You can get the letter here. It arrives on Sundays. This first edition gives you the background; the next ones can spend more of their time on what changed.
Where we stand
Before buying our first building, we set ourselves the goal of running the properties we owned unusually well. We bought software, tried to connect it and gradually found ourselves changing our operation to suit the products. A fault report could become a contractor visit, an inspection and eventually a maintenance decision. The work belonged together even when the software divided it up.
Building our own systems began there. Our operations system has been through three versions. The third was locked in September: a record of what each building contains, controls activated for each property, work orders carrying a copy of their requirements, and evidence of the work recorded against them. It was built without an in-house developer. The database structure and functions were written by hand in SQL before Lovable generated the interface.
On 9 October we exported the code and prepared a separate database for testing. Before adding functions, we asked Claude Code to read the system and describe what it actually guaranteed. Then we tested the database as the users who could reach it.
The function that completed a control order already refused to run without evidence. A direct update of the order could bypass it. The interface offered no way to edit or delete evidence, but the database allowed both. The requirement copied into an order could also be changed after the order was created. We had described some of these rules more strongly than the mechanisms supported.
Ten changes were tested on staging, one at a time. Melker then applied them to the live database himself, comparing the checks before and after each step with staging. The coding agent had no production login. From 9 October, editing, deleting and truncating evidence, changing the order snapshot, reopening a finished order and completing a control order without evidence are refused by the database for every application role.
There are limits to that statement. The database owner can deliberately disable the triggers through the SQL editor. The evidence gate counts records; it does not judge whether a photograph or protocol proves the work was done properly. The database records when evidence arrives alongside the time supplied for when it was captured. A late submission can therefore be seen without pretending the system witnessed the work itself.
Our founder tells the fuller story in The week we became visible. The system had been useful in daily operations before the test. The findings changed the guarantees we could claim for it, and the checks we require before extending it.
FROM THE LAB
Version 4 is under way on the same database, with the hardening phase, 4.0, now in production. The next phase is the inbox: a shared place for incoming messages and notes, connected to the property’s existing records. Its first steps are a table, manual triage and a named agent with a limited reading role. Public fault reporting and email intake come later in that phase. Tasks, documents and a tenant portal are further planned layers; they are not part of the system in use today.
SIGNAL
An agent that can keep working between requests
What happened. OpenAI announced Dots on 29 September: agents with their own cloud computers that can retain context and work between conversations. Availability began with selected plans and markets.
For an operator. A continuing assistant makes it possible to follow work over time. The permissions it receives determine which records and actions that continuity reaches.
Our position. We are building the reading role and the system’s access points first. An agent will have its own identity and a visible trail. It will never close orders or write evidence. Dots is a possible client for those access points later; no external agent is connected yet.
Models that return a decision you can use
What happened. OpenAI’s Decisions API entered public beta on 6 October. It returns typed outputs from text or images, including choices among predefined answers, rather than an open-ended response.
For an operator. Classification can help sort incoming work: a fault report, a document or a request that needs a person to decide. A fixed answer format makes the output easier for software to handle; accuracy still needs checking.
Our position. Decisions API and Jev are design alternatives for inbox triage. We have not tested either in our inbox. A message about a cold radiator needs its source and history preserved, and an uncertain classification needs to stay uncertain until someone checks it.
Using an existing ChatGPT plan in a participating tool
What happened. OpenAI’s Sign in with ChatGPT integration, documented on 28 September, lets eligible users authorise participating tools to use their ChatGPT plan for AI requests. Identity sign-in and plan usage are separate permissions.
For an operator. This can remove the API-key setup from trying a supported tool. Eligibility, permitted requests and usage limits still matter; an existing subscription does not pay for every app you build.
Our position. We are keeping this as an option to evaluate. It does not change the roles or evidence rules inside our system, and we have not added it to our operation.
IN THE JOURNAL
Five pieces are published. Start with the one closest to the work you are trying to improve.
Article / 001: The big shift in AI and real estate isn’t new software. How building around an operation became possible for an operator without an in-house developer, and what our successive attempts taught us about the cost of doing it.
Article / 002: There is no best AI tool. How we choose tools for the work in front of us, including the move from a first interface to changes in a system already in daily use.
Article / 003: The survey was right about every pipe it saw. A partial survey became the basis for a whole-building decision. The piece follows what the report left out and what we now ask for in an inspection brief.
Note / 001: The company came afterwards. Melker on how the work in our buildings, his interest in technology and the wish to write gradually became RENAVID.
Note / 002: The week we became visible. The first public week, the move to code and the database checks that changed the order of the next build.
Reply and tell us one thing about your operation: which piece of work is hardest to follow all the way through? It shapes what we write next.
RENAVID · renavid.com
Free. Sundays.