I decide what gets built, then write it so someone else can run it.

Executive leadership

For several years my own health stopped fitting in a chart, a supplement list, or a single diagnosis. Labs, papers, food logs, training notes, and physician records sat in different files, and more of them did not produce a clearer decision. I started NRTR because I needed one model of what had changed, what contradicted a guess, and what was still missing. I was one of the first people to run my life on it. I put about $80,000 of my own money into the work before it was a company other people could use.

That is still how I lead. I would rather a customer understand the system and keep their own record than buy a promise that one protocol fits every body. Compassion here is practical: people get more room to act when the picture is honest, including when the picture says we do not know yet. I want commerce that does that. A sale should leave the buyer more able to run the work, not more dependent on the person who sold it.

At NRTR I direct product, contractors, partnerships, and pricing, and I prepare the materials we use with advisors and investors. The company reports more than 2,000 users and more than 100 practitioners. The product connects history, observations, training, nutrition, and practitioner review, and the record stays on the operator’s machine.

At Sigil42 I run a core group of about six people plus contractors. We sell workflow and cost work, do the first installs ourselves, and write the install down so it can be staffed. I have written the statements of work and sat in the sales conversations, including the objections. One of those conversations became a formal partnership. The same rule applies: the customer should be able to keep the process after we leave.

From 2021 I have advised about 20 to 50 owners of small businesses and coaching practices on offer, positioning, and operations. Some of those businesses grew about two to ten times. Not every engagement did. I helped run a Nashville event of more than 400 people, and audience channels I ran passed 10,000 followers together. Growth counted when the operation could still be explained and repeated, not only when the top line moved.

Head of product strategy

The first version of the product was a stack of protocols built from what I was learning while I was sick. It failed in the way a static plan fails: my own biology kept changing, and a recommendation from last month could be the wrong move this month. The product decision after that was to stop shipping a one-time list of things to try. The system had to keep a history, notice what happened before a change and what happened after, and update.

A second decision followed from the same place. Health data had been living in hosted stores I did not control, split the way my own records had been split across spreadsheets and PDFs. I wrote those collections down first: more than 100 stores and about 30 workflows. Two people rebuilt them in a database on the operator’s machine in about two days. The document was the plan. The rebuild showed the document was good enough to execute.

I refused a second health record inside the model. A model may propose. The application writes the decision and names the inputs it used. If the model is down, the record and the rules that do not need a model still work. The screen says the suggestion is unavailable. It does not invent one. Inventing a result would have been an easier product and a worse one.

Practitioners were a distribution choice, not a campaign. I wrote a course of about 20 modules and taught more than 30 people. I changed the lessons where the same misunderstanding kept showing up. About 89 percent passed the first sitting. Everyone who stayed finished after the extra teaching.

At Sigil42 the strategy is the same shape in another market. Do the customer’s workflow with them. Keep what survives contact with the work. Turn that into a procedure someone who was not in the room can run. On the consumer chat product I set the offer and the message. Other founders own the engineering.

Head of AI

I did not come to this from a model demo. I came to it after years of reading physiology, metabolism, immunology, training, genetics, and the papers around them, and still being unable to hold the contradictions in my head. The useful question stopped being which supplement matches a symptom. It became what changed upstream, which guess the new fact breaks, and which measurement would reduce the uncertainty. NRTR is that question, built so it can be asked again next month.

The research systems came out of the same limit. I directed more than 15 pipelines that collect and arrange papers from sets larger than 100,000. I have personally read or written up more than 10,000 papers. The pipeline does not replace that reading. A claim in the knowledge base still needs a source, a method, and a confidence. A protein record is one amino-acid sequence. A lab value, a gene name, and a disease link are filed somewhere else. Mixing them is how a confident system becomes a wrong one.

On the codebase, about 500,000 lines, coding tools were producing changes that took weeks to bring back in line with the design. I wrote about 1,900 records tied to files and functions. A tool reads the records for the files it is about to change. If none come back, it stops. After the edit, those records are updated. Against prompting with no records, rewrite work fell by about 90 percent. The tool is allowed to help. It is not allowed to forget what the system already decided.

I wrote NRTR: The System, about 300 pages, on the health method, behavior, and how a protocol is put together. The method is track, connect, name the gap, test, watch the response, and update. That is the loop I had to use on myself. I wrote it down so another person can follow the same steps and see where a conclusion came from, instead of taking my word for it.

Technical documentation

The documents started as the only way I could see my own case. A genome, a lab panel, a training log, and a stack of papers are not a decision until someone writes down what each one is allowed to mean, and what it is not allowed to mean. I still write that way. A document is finished when another person can act from it and can tell when they should stop.

At the University of Colorado Anschutz I had already watched research operations fail in the same pattern: study teams, regulatory files, and the electronic systems did not share one procedure, so the same startup work broke in the same places. I supported about 1,000 study teams, wrote more than 50 procedures, and prepared or checked more than 150 regulatory files. Active use of the electronic systems rose about eightfold, to roughly 150 people. The procedures were there so staff could finish the work without waiting on me.

At NRTR that became more than 500 documents: setup, interfaces, architecture, specifications, operations, research notes, product behavior, and training. The living set is about 1,900 records on the code itself, so a change in the source updates the note that describes it. At Sigil42 I wrote about 30 specifications for a codebase of about 200,000 lines, scoped so a contractor could build the assigned part. Giving someone the whole design when they need one piece is sloppy, and it is also how private architecture leaks.

Read Documentation Examples