A question worth answering before AI starts answering it for you. This is a business-user's guide to the TELOS method — a framework for structured self-knowledge that AI can actually use. Read it. Then build your own.
Open ChatGPT, Copilot, Gemini, Claude. Type a question. The model doesn't know you. It doesn't know what you do, what you care about, what you've already tried, how you like to communicate, what tone fits your work, what would be useful versus generic.
So you spend the first three sentences explaining yourself. Or you don't, and you get a generic answer back. Then you do it again. Fifty times this week.
The problem isn't the model. The problem is the context you never give it. And the deeper problem is that most of us couldn't articulate that context if asked, because we've never sat down to articulate it to ourselves.
"The bottleneck on good AI answers isn't the model. It's how clearly you can say who you are and what you're trying to do."
— Adapted from Daniel MiesslerDaniel Miessler's framing: the real promise of AI isn't smarter answers. It's that the friction between having a thought and acting on it collapses toward zero — but only if your AI has enough context to act intelligently on your behalf.
Generic. Polite filler. You could send this email at any company in any industry — which is exactly the problem.
Same model. Same prompt. The TELOS context is doing the work. The output is now a real email someone could actually send.
Daniel Miessler's TELOS framework is a structured way to write down what you're about — your problems, your mission, your goals, your strategies, your projects — so that any AI tool can be handed that context and act on it. You write it once. You give it to your tools. You update it as you change.
Tap each step to read what it means
The fundamental things you believe are broken — in your work, your industry, the world — that you want to address.
Problems are the deepest layer. They explain why you do anything. Without naming the problems you care about, every goal you set is arbitrary and every project drifts.
Most people skip this step and go straight to goals. That's why their work feels disconnected — there's no root they can trace it back to.
"Most operational decisions in our business are made on instinct because the data exists but isn't connected. Good people make worse decisions than the data would suggest."
What you've decided to do about those problems. One sentence, ideally.
Your mission is the action commitment that follows from your problems. It's not a corporate slogan. It's the specific stake you've put in the ground.
A good mission is narrow enough to actually pursue and broad enough to span years. If it fits the next 18 months exactly, it's a goal, not a mission.
"Make data-driven decisions the default — not the exception — in operations functions across mid-sized industrial businesses."
The specific outcomes that, if achieved, would constitute real progress on your mission.
Goals are measurable. They have horizons. They are the thing you'd celebrate hitting. Each goal should be traceable back to one of your problems — if it isn't, ask yourself why it's on your list.
Three to five goals is usually right. More than that and nothing gets attention.
"Reduce unplanned production downtime by 30% in 12 months." · "Move 80% of weekly operating reviews from PowerPoint to live data by Q3." · "Get every site supervisor fluent in our analytics platform by year-end."
The approaches you'll use — the how. Distinct from projects, which are the what.
A strategy is a principle that guides many decisions. It's the bet you're making about which approach will work.
Strategies are where your judgment lives. AI can help you generate projects all day long, but it can't tell you which strategy fits your context. That's still your call.
"Instrument before optimizing — never improve a process we can't yet measure." · "Train the line workers, not just the analysts — the data must reach the floor."
The concrete work you're doing right now to execute on your strategies.
Projects are time-bound, finishable, and assignable. Each one should ladder up clearly: This project executes this strategy, which pursues this goal, which addresses this problem.
If a project doesn't ladder up — kill it, or rewrite the chain. This is where TELOS earns its keep as a thinking tool, not just a document.
"Sensor rollout to Sites 4–6, Q4." · "Weekly ops review redesign, Sept–Nov." · "Pilot supervisor training cohort, Aug–Oct."
"You can't explain how you work to an AI without first understanding it yourself. But you can use AI to help you extract and understand it."
— A reader of Daniel Miessler's frameworkTwenty minutes. Five fields. Don't try to be perfect — the act of writing is most of the value, and you'll rewrite it many times. When you're done, download the markdown file and paste it into whichever AI tool you use most.
For the header of the file — and so AI tools know who they're talking to.
A sentence or two: what you do, where, with whom. This is the surface-level context most people stop at.
What's broken that you care about? Two or three things. Be specific — "inefficiency" isn't a problem, "we spend four hours every Monday rebuilding the same report" is.
One sentence about what you're doing about those problems. Not a slogan. Your actual commitment.
Three to five measurable outcomes. Each one with a horizon. If you can't measure it, sharpen it until you can.
The principles guiding how you'll pursue the goals. Your bets about what will work.
What you're actually working on right now. Date-bound. Each should ladder up to a strategy above.
How you want AI to talk to you and write on your behalf. Tone, length, words to avoid.
A markdown file isn't a developer artifact. It's just structured plain text. Every major AI tool now has a place to keep persistent context — you just need to know where.
This page is a translation of Daniel Miessler's work into a business-user idiom. The originals are excellent and worth your time — especially the second video, which is the philosophical heart of the framework.