If you build in AI, robotics, or deep tech, you will share your work in public sooner than you think. A talk. A demo day. A partner meeting. A “soft launch.” A single slide in a pitch deck. A short clip on social media.
And that is where many founders lose patent rights without meaning to.
This article is about the quiet ways “public disclosure” happens, why it matters, and how to keep your options open while you still move fast. If you want to protect what you are building before you show it, you can apply anytime here: https://www.tran.vc/apply-now-form/
What “public disclosure” really means
Public disclosure means you shared enough details about your invention that someone outside your trusted circle could understand it. It does not always mean a big press release. It can be small. It can be casual. It can be a “harmless” screenshot.
Founders often picture public disclosure as standing on a stage and announcing the full design. In real life, it is usually a mix of small moments that add up. A photo of a prototype. A slide with system architecture. A GitHub snippet. A demo video that shows the key trick. A poster at a conference. A talk where you explain the “secret sauce” because you want to sound credible.
Why this matters is simple: patents are about being first to file, not first to build. If you disclose before you file, you may lose rights in many places. Even where there is a grace period, you are taking a risk that is often not worth it. The rules differ by country, and the stakes are high. One early disclosure can lock you into a narrow path.
There is also another problem that does not get enough attention. Even when you technically still can file later, early disclosure can make your patent weaker. It can shrink what you can claim. It can create “prior art” that is used against you. It can give a competitor a map of where to attack.
So the goal is not to hide forever. The goal is to control timing. You want to file before you disclose the key parts.
Tran.vc exists to help founders do that without slowing down. We invest up to $50,000 in in-kind patent and IP services so you can protect the real invention while you still ship and talk to the market. If you want to start that process, apply anytime: https://www.tran.vc/apply-now-form/
The three places founders get trapped: conferences, demos, launches
Most disclosure accidents happen in three settings.
First, conferences. These are built for sharing. The whole point is “show your work.” You want attention. You want to meet partners. You want to recruit. So you share details that you would never put in a public blog post. You do it because the room feels safe. It is not safe. Anyone can take notes. Many sessions are recorded. Slides get posted. People take photos. Someone live-tweets your “one key insight.”
Second, demos. Demos are even more dangerous because they feel like a performance. You want to prove it works. So you show the pipeline. You show the interface. You show the model behavior. You show latency and edge cases. In robotics, you show the mechanical setup, the sensor placement, the control loops, the safety layers. You do not say “this is our method,” but you still reveal it.
Third, launches. Launches make disclosure permanent and searchable. A product page. A technical post. A video. An open beta. A “build in public” thread. This can be great for growth. It can also erase your ability to protect the core idea if you do it too early.
Now let’s make this practical. Let’s talk about what counts as disclosure in each case, what founders do that triggers it, and how you can avoid it while still getting the upside of being visible.
Conferences: where “sharing” becomes a legal event
Conferences feel like the right place to show off. You get validation from peers. You meet the right people in one day. You feel the energy. For deep tech, this is often where you first get taken seriously.
But conferences are disclosure machines.
A keynote is public. A panel is public. A poster is public. A workshop can be public. Even a hallway chat can become public if the person you talk to is not under a duty of confidence. That last part is key. The law does not care that you “trusted” the person. It cares whether there was a real obligation to keep it private. In most cases, there is not.
The biggest trap at conferences is the slide deck.
Founders spend weeks making slides. They add a “how it works” diagram to look credible. They add system design boxes. They add training data flow. They add metrics. They add a video of the robot doing the thing. They add the diagram that shows the special component.
Then they present it once. They think it disappears.
It does not. Slides often get requested. They get uploaded. They get forwarded. Photos of slides get shared. Even if you never share the deck, the audience can capture it. If the conference records the talk, the details live forever.
A second trap is the paper or abstract.
If you submit an abstract that includes the key method, that is a disclosure. If you publish a workshop paper, that is a disclosure. If you upload a preprint, that is a disclosure. If you put a PDF on your site, that is a disclosure. Even a short “methods” section can be enough.
A third trap is the live demo at your booth.
At booths, people ask blunt questions. “How did you do this?” “Is it vision-only?” “What controller do you use?” “How do you handle drift?” “What is the trick for grasp stability?” You want to impress them. So you answer. You show the pipeline. You pull up dashboards. You show logs. You show the training loop.
That is often where the real invention leaks out. Not on stage, but in a friendly conversation with someone who “seems like your kind of person.”
So what do you do?
You do not stop going to conferences. You just go with a plan.
The plan starts with one simple rule: if it is the part you would want to patent, do not describe it in a way that teaches it.
That sounds obvious, but the line is not always clear. Here is a useful way to think.
It is usually safe to talk about the problem, the outcomes, and the results. It is risky to talk about the specific mechanism that makes your result possible.
For example, in robotics, you can show that your robot can pick fragile objects. You can show the speed. You can show the reliability. But you should be careful with the exact sensor layout, the calibration method, the control strategy, and the error handling that makes it reliable.
In AI, you can show that your model beats baseline performance. You can talk about the user value. But you should be careful with the exact training recipe, data curation steps, labeling strategy, architecture modifications, and the unique evaluation method that proves the edge.
Notice something: you can still sound smart without giving away the recipe. You just need to practice that style of communication.
A practical approach is to build two versions of your story.
The public story is what you say on stage, in slides, in posters, and in anything that might be photographed.
The private story is what you share only under a signed NDA, or in a setting where a real confidentiality agreement is in place, and only after you have filed.
Founders often resist this. They worry that if they do not share the “how,” nobody will care. That fear is real, but it is usually wrong. People care because you solved a hard problem. They do not need your exact method to believe it is hard.
Also, the “how” you disclose is rarely what makes people invest anyway. The best investors want to know you can execute and that your moat can grow. You can prove that with traction, with a crisp explanation of why the problem is hard, and with evidence that your solution works. You can save the patentable core for a protected setting.
There is another tactic that works well at conferences: decide in advance what you will not answer.
Have a calm, polite sentence ready. Something like, “We keep the internal method private for now, but we are happy to talk about outcomes and use cases.” Say it with confidence. Most people respect it. The ones who push are often the ones you should not be feeding.
Now here is the key part: if you already disclosed at conferences in the past, you may still have options, depending on where you plan to file and when the disclosure happened. But you should treat it as urgent. The longer you wait, the more you risk.
If you want help mapping what you have already shared and what you can still protect, Tran.vc can help. We invest in patent strategy and filings so you do not have to guess. Apply anytime: https://www.tran.vc/apply-now-form/
Public Disclosure Traps: Conferences, Demos, and Launches
The hidden cost of “just sharing”
If you build in AI, robotics, or deep tech, you will show your work in public early. It might be a quick demo at a meetup. It might be a few slides at a conference. It might be a “soft launch” post on LinkedIn.
Most founders think this is harmless marketing. In many cases, it is a legal event. The moment your invention is shared in a way others can understand, you may lose patent rights in many places.
The painful part is how quiet it is. You do not get a warning. You do not get a pop-up that says “you just disclosed.” You only find out later, when you try to protect the invention and the window is already smaller.
If you want to protect what you are building before you show it, you can apply anytime here: https://www.tran.vc/apply-now-form/
What this article will help you do
This article will help you spot the traps before they happen. You will learn what “public disclosure” really looks like in the real world, not in a textbook.
You will also learn how to speak in public without teaching your secret steps. You can still win trust, attract partners, and raise capital, while keeping your patent options open.
The goal is not silence. The goal is control. You decide what is shared, when it is shared, and how far it goes.
Conferences
Why conferences cause trouble fast
Conferences are built for sharing. People come to learn, compare approaches, and copy what works. That is not bad. It is the point of the event.
The problem is that founders often treat conference rooms like closed rooms. They are not. Most talks are recorded, photographed, live-posted, or summarized in notes that travel far beyond the event.
A single session can create a long trail. Slides get emailed. Photos of slides get posted. A “small” diagram becomes a permanent clue for anyone watching your space.
The slide deck trap
Slide decks are the number one place founders leak the method. You add one diagram to look credible. You add one flow chart to make the story “clear.” You add one block that shows the pipeline.
In your mind, that is not the invention. It is just an explanation. To a patent examiner, or a competitor, it may be enough to understand your unique steps.
Even if you never share the deck, the audience can capture it. Phones can zoom. People can screenshot recordings. The details do not stay inside the room.
Posters, abstracts, and workshop papers
A poster can be even worse than a talk, because people stand close and read every line. They take photos of the key section. They zoom in later. Posters are built to teach, so they often include the exact “how.”
Abstracts and workshop papers can also count as disclosure. Many founders think an abstract is too short to matter. But even a short methods summary can reveal the non-obvious step.
Preprints and PDFs are especially risky because they carry a date. They are searchable. They often get indexed and cached, even if you remove them later.
Booth demos and hallway chats
Booth demos feel casual, but they are sharp. People ask blunt questions. They want the trick. They want the design choices you made that others missed.
Hallway chats are the same. Someone says, “We are working on something similar.” You feel safe. You share more than you planned.
The issue is not that people are evil. The issue is that most of them are not bound to keep your details secret. If there is no duty of confidence, it can count as public.
How to speak publicly without teaching the invention
You can share outcomes without sharing mechanisms. Outcomes are what the tech does, how well it works, and why it matters to users.
Mechanisms are the special steps, the unique structure, and the non-obvious choices that make the outcome possible. Those are the parts you usually want to protect.
A strong public talk focuses on the problem, the constraints, the results, and the impact. It can still be technical, but it avoids giving a “recipe” someone else can follow.
The two-story method: public story and private story
The simplest way to stay safe is to build two versions of your story.
Your public story is what you can say on stage and in slides without worry. It proves you solved a hard problem, but it does not teach the method.
Your private story is what you share only after you file, or in a setting where there is real confidentiality. That story can include deeper details, because your filing date is already set.
This keeps you moving fast. You do not have to freeze your marketing or your networking. You just keep the important parts under control.
What to do if you already disclosed at conferences
If you already presented details, do not assume it is over. Options may still exist depending on timing and where you plan to file.
But you should treat it as urgent. Each week you wait can close doors, or shrink what you can claim later.
If you want help mapping what you shared and what can still be protected, Tran.vc can help. Apply anytime here: https://www.tran.vc/apply-now-form/
Demos
Why demos feel safe, but are not
Demos are meant to create belief. They are powerful because they show real behavior, not promises.
But demos often reveal more than founders realize. A working system exposes clues, even if you never explain it out loud.
Also, demos are often recorded. A short video can get shared many times without you knowing. Once it spreads, you cannot pull it back.
The video problem
A demo video can disclose even when it is silent. In robotics, the camera angle can show your setup, your end effector, and how your robot reacts under stress.
In AI, the user flow can reveal what is automated, what is inferred, and what is validated. Outputs can hint at the training approach. Timing can hint at the runtime design.
If you add captions, you raise the risk. If you answer questions in the comments, you raise it again. The video becomes a public record of your method over time.
Live demos that turn into debug sessions
A common pattern is that the demo breaks. Then you fix it in front of someone. To fix it, you open internal tools.
You show dashboards. You show logs. You show how the model is called. You show the safety checks. You show the control loop states.
This is the exact moment the invention leaks, because the debug view is often where the real system is visible. You did not mean to reveal it, but you did because you wanted the demo to succeed.
Investor demos are usually not private
Many founders assume investor meetings are protected. They often are not.
Most investors do not sign NDAs. That does not mean they will steal your work, but it does mean your disclosure may still count as public in many cases.
Even ethical investors take notes. They discuss deals internally. They may refer founders to others. Your deck and your explanation can travel wider than you think.
The safe demo goal: prove value, hide mechanism
A safe demo is designed around what the audience needs to believe.
They need to believe it works, that it solves a real pain, and that it performs better than the other options. They do not need your internal recipe.
So you design the demo to show outcomes clearly, while avoiding views that teach the method. This is not about being secretive. It is about being deliberate.
Demo design choices that reduce disclosure risk
For robotics, camera placement matters. What is in frame matters. If the key invention is in the workcell layout or sensor setup, you avoid showing it closely.
For AI software, what screens you show matters. Internal admin panels, prompt logs, training dashboards, and evaluation harnesses are often packed with patentable details.
A “clean” demo environment helps. You show the product view, not the engineering view. You avoid opening tools that expose the internal flow.
Customer site demos and the photo problem
On-site demos feel controlled, but they are often the opposite. Customers have teams, partners, vendors, and visitors. People take photos.
Even if nobody means harm, someone may post a picture online because they are excited. That picture can reveal your prototype and your approach.
A basic confidentiality agreement and simple rules about photos can reduce risk. Still, the best protection is filing before major on-site demos.
Tran.vc helps founders do this without slowing down. Apply anytime here: https://www.tran.vc/apply-now-form/
Launches
Why launches create permanent disclosure
A launch is not just public. It is also easy to find later.
It is indexed. It is dated. It is screenshotted. It is cached. Even if you delete it, copies often remain.
That makes launches a serious disclosure risk. Your own marketing materials can later be used to limit what you can claim, or to argue your invention was already public.
“Build in public” can become a slow leak
Build-in-public content is rarely one post. It is a sequence.
Week by week, you share progress. A small chart here. A diagram there. A training tip later. A deployment trick after that.
Each piece may feel safe alone. Together, they can reveal the full method. This is one of the most common modern disclosure patterns.
The technical blog post trap
Technical posts are great for hiring and trust. They are also the fastest way to disclose the non-obvious parts of your work.
A post that explains how you achieved a performance jump often includes the exact steps that make your system special. That is the part you might want to patent.
Founders often regret this later, not because the post was “wrong,” but because the timing was off. They shared too early.
Open sourcing too soon
Open source can be a smart strategy. It can also burn your options if you open source the core invention before you file.
Once code is public, it becomes prior art. It is a dated record. Even if you later close the repo, the content can live on in forks and archives.
If you plan to open source, the clean path is to file first, then share. That way you keep protection while still getting the open-source benefits.
A safer launch strategy: share what, not how
You can launch without teaching.
You talk about the user problem, the results, and the impact. You show proof that it works. You show the product experience.
But you avoid publishing the special steps that create the edge. You can still be clear and confident without giving the recipe.
File, then share
For many founders, the best rule is simple.
If you are about to publish something that reveals a real invention, file first. Then publish.
This keeps your pace. It also reduces stress. You do not have to guess whether a post is “too much.” You just set the date, then move forward.
Staged depth over time
You can plan your content in layers.
Early content builds trust and interest without deep detail. Later content goes deeper after filings are in place. The deepest content comes once your IP base is strong.
This allows you to keep growing your audience without giving away your moat early.
If you want help building that plan, Tran.vc can support you with strategy and filings. Apply anytime here: https://www.tran.vc/apply-now-form/
The quiet disclosures founders miss
Many disclosure problems do not come from big events. They come from small moments.
A pitch deck that gets forwarded. A Notion page shared by link. A Google Doc set to “anyone with the link.” A candidate interview where you over-explain. A vendor call without a real confidentiality agreement.
These moments feel private. They often are not.
The founders who avoid this are not paranoid. They simply run a light process. They know what is patentable. They know when they are about to share it. They protect timing.