The Blueprint: Why OpenYF is Building in Public

Our philosophy on radical transparency in AI development and the importance of open-source cognitive layers.

I am 18 years old and I am trying to build an AI research lab.

I say that not to be impressive. I say it because it is the most honest way to explain why we build the way we do. When you have no money, no team, no institutional credibility, no track record — transparency is not a strategy. It is the only real option.

But the longer I have been building, the more I believe it is also the right option. Not just for us specifically, but for anyone working on systems this consequential.

There is a version of OpenYF where we build in secret. We protect our architecture. We do not publish the audits. We do not talk openly about what is broken. We wait until everything is polished and then announce.

That version has a fatal problem: no one is watching.

When you build hard things in secret, the only feedback you get is your own. And you are the worst possible judge of your own blind spots. You built the system. You cannot see what you cannot see.

The memory audit found nine issues with VYN's memory system (powered by the ARIA engine). Seven of them were problems I had created myself and then stopped noticing because I was used to them. The stale self-reflection was not a mistake I made carelessly — it was a mistake I made confidently. I thought the system was working. It wasn't.

Building in public is not about marketing. It is about forcing accountability at a stage when accountability is most inconvenient. When the code is messy. When the architecture is half-finished. When the honest description of the project is "promising but broken in specific ways."

That is exactly when external eyes matter most.

There is also a deeper reason, specific to what we are building.

VYN is, in its current form, a prototype of something that could eventually become very capable. The phases we are working through — persistent memory, world models, self-improvement loops, recursive self-modification — are not arbitrary feature choices. They are the pieces that, assembled correctly, produce an agent that can learn without limit.

That is not a threat. It is the goal. But it means the architecture deserves scrutiny that no single person or closed team can provide.

The alignment problem — ensuring that increasingly capable AI systems pursue goals that are actually good — is not solved by good intentions. It is solved by transparent systems that can be understood, audited, and corrected by people who are not the original developers.

Every decision we make about how VYN represents knowledge, how it prioritizes goals, how it modifies its own behavior — these are decisions that affect anyone who eventually uses it. The people who should have input on those decisions are not just us.

Building in public is how we make room for that input before the system is too mature to easily change.

It does not mean posting polished announcements when things succeed.

It means publishing the forensic audit that found we had written a safety lock that was "conceptual and a database status field, not an unbypassable architectural gate." It means being specific about which phase is genuinely complete and which phase is mostly scaffolding. It means saying when the install experience fails on Windows for 40% of users instead of pretending the launch was smooth.

Most build-in-public content is really launch-in-public content. Carefully timed announcements of finished things, designed to generate momentum. That is not what we are trying to do.

We are trying to document the actual process of building a cognitive agent architecture. The failures matter as much as the successes because the failures contain the most information. A system that self-reflects and then discards the reflection is interesting not just as a bug, but as a pattern — it tells you something about how easy it is to build data collection without closing the feedback loop.

Those patterns are worth publishing. Not because they make us look good, but because the next person building something similar should not have to find them the same way we did.

I started building because I could not tolerate the alternative. Not in a dramatic way — I am not opposed to normal life. But there is a kind of life that involves only consuming what already exists, only occupying roles that were designed before you arrived, only progressing along paths that do not require you to invent anything.

That life is fine for many people. It was not going to be fine for me.

Building in public is partly a commitment device. When you announce what you are building, when you document the architecture openly, when you publish the failures alongside the progress — you create accountability to something outside your own discipline. On the days when the lock file is broken again and the install audit gives you a 40% success rate and you wonder what you are doing, the public record of what you said you were building is a reason to continue.

Not because anyone is watching. Often very few people are watching at the beginning. But because you have said something and you have to either mean it or admit you do not.

OpenYF will not remain one person building alone. The architecture we are documenting publicly, the decisions we are explaining openly, the failures we are publishing honestly — these are not just content. They are an invitation.

The right people, reading the right posts, finding the right audit findings — will want to contribute. Not because we have a lot of users or a lot of funding, but because the problems are real and the work is honest.

That is how labs actually start. Not with a big announcement. With a track record of taking hard problems seriously and telling the truth about what you found.

We are building that track record now, one post at a time.