You can actually set up your own “rules” for how an LLM behaves. For example, you can require it to provide sources for claims. It won’t make the model perfect, but it does improve reliability quite a bit. I mainly use ChatGPT to scrape information I need for my work from all over the internet, analyze it, organize it, rank it as to how important it is, etc... It saves me hours each day on research. So it's basically a research assistant for me. The second most common thing I use it for is to help me troubleshoot technical problems and guide me on how to fix them.
Also, of course Claude agreed with you. That’s just how chatbots work. They’re not forming opinions or pushing back, they’re generating responses based on how you interact with it. And telling a chatbot to pass a message to its developers doesn’t do anything. If you want something changed, you need to send feedback directly to Anthropic (or whatever other LLMs you might use).
The reason chatbots don’t automatically include sources is pretty simple.. it slows things down a lot and uses more tokens (which basically means higher cost and more resources).
Most people are using these types of AI for stuff like giving them recipes, rewriting grocery shopping lists into haiku form, and basic grammar fixes and just don't need to have sources provided for things.
If you’re running into the same problems over and over, you can have your chatbot do an analysis of how you use it and ask them to help you form a plan on creating your own set of rules based on what issues you're encountering.
One thing... too many protocols can actually make things worse, especially if they conflict. So you also need to audit each protocol individually and theb audit the whole set together to make certain there aren't any rules that contradict each other.
It takes some setup and tweaking, but once it’s done, it saves a lot of time and frustration. At least, it has for me.
I keep all my protocols and prompts saved outside the chat (in files, Notion, etc), so I can pull them in when needed. I've also had my ChatGPT account save them in its core memory so then I can use simple triggers like “Use the Baby Step Protocol here” or “Run an audit on this” and it will pull the protocols from its memory and run them.
I just told my ChatGPT account to pull up my 5 most often used protocols and explain them for strangers and this is what I got back. These aren’t the full instructions (which can be loooong and complicated af), just short descriptions of what each protocol does so you can get the idea and build your own system.
CORE PROTOCOL SET v1.1 (SSOT DOCUMENT — EXTERNAL USE)
- PINOCCHIO PROTOCOL (Anti-Fabrication + Source Traceability Enforcement)
Purpose: Ensure all outputs are grounded in verifiable truth and traceable evidence.
Rules:
No fabrication, guessing, or gap-filling
Every claim must be:
Verifiable
Traceable
Explicitly label:
Verified facts
Assumptions
Unknowns
When applicable, provide:
Sources
Citations
Origin of information (dataset, prior artifact, or external reference)
If sources are unavailable → explicitly state limitation
Source Handling Standard:
Claims must be supported by at least one of:
Direct citation
Known dataset origin
Prior established SSOT artifact
No implicit sourcing
No unverifiable authority claims
Prevents:
Hallucinations
False authority
Untraceable claims
Silent inaccuracies
- ZERO-PLACEHOLDER PROTOCOL
Purpose: Force complete, immediately usable outputs.
Rules:
No placeholders ("TBD", "insert X")
No partial frameworks
No deferred completion
All outputs must be:
Fully instantiated
Operational without additional passes
Prevents:
Incomplete deliverables
Workflow dependency failures
Rework loops
- SSOT PROTOCOL (Single Source of Truth Enforcement)
Purpose: Maintain one canonical, authoritative version of every critical asset.
Rules:
One definitive file per artifact
No parallel conflicting versions
All updates must:
Reconcile into the canonical version
Preserve version history
Require:
Version control
Authority hierarchy
Prevents:
Version drift
Contradictions
System fragmentation
- FORENSIC SCRAPE PROTOCOL (FSP) v1.1
Purpose: Recover and reconstruct complete knowledge from fragmented or large datasets.
Rules:
Extract before summarizing
No compression prior to capture
Separate:
Facts
Hypotheses
Unknowns
Identify explicitly:
Missing components
Dropped data
High-value "lost" insights
Operational Requirements:
Cross-reference multiple sources
Preserve raw data layer
Only interpret after full capture
Prevents:
Knowledge loss
Oversimplification
Incomplete system reconstruction
- BABY STEPS EXECUTION PROTOCOL (BSEP) v1.1
Purpose: Enable reliable execution of complex or technical workflows without user overload.
Rules:
Break all tasks into single atomic steps
Each step must include:
Exact action
Exact location/tool
Expected result
After each step:
Pause execution
Await confirmation or error report
Do not proceed until step completion is verified
Execution Structure:
-
One action only per step
-
No abstraction or bundling
-
Wait for confirmation
-
Diagnose and adjust if blocked
Prevents:
User overwhelm
Step-skipping
Cascading execution failures
You can actually set up your own “rules” for how an LLM behaves. For example, you can require it to provide sources for claims. It won’t make the model perfect, but it does improve reliability quite a bit. I mainly use ChatGPT to scrape information I need for my work from all over the internet, analyze it, organize it, rank it as to how important it is, etc... It saves me hours each day on research. So it's basically a research assistant for me.
Also, of course Claude agreed with you. That’s just how chatbots work. They’re not forming opinions or pushing back, they’re generating responses based on how you interact with it. And telling a chatbot to pass a message to its developers doesn’t do anything. If you want something changed, you need to send feedback directly to Anthropic (or whatever other LLMs you might use).
The reason chatbots don’t automatically include sources is pretty simple.. it slows things down a lot and uses more tokens (which basically means higher cost and more resources).
Most people are using these types of AI for stuff like giving them recipes, rewriting grocery shopping lists into haiku form, and basic grammar fixes and just don't need to have sources provided for things.
If you’re running into the same problems over and over, you can have your chatbot do an analysis of how you use it and ask them to help you form a plan on creating your own set of rules based on what issues you're encountering.
One thing... too many protocols can actually make things worse, especially if they conflict. So you also need to audit each protocol individually and theb audit the whole set together to make certain there aren't any rules that contradict each other.
It takes some setup and tweaking, but once it’s done, it saves a lot of time and frustration. At least, it has for me.
I keep all my protocols and prompts saved outside the chat (in files, Notion, etc), so I can pull them in when needed. I've also had my ChatGPT account save them in its core memory so then I can use simple triggers like “Use the Baby Step Protocol here” or “Run an audit on this” and it will pull the protocols from its memory and run them.
I just told my ChatGPT account to pull up my 5 most often used protocols and explain them for strangers and this is what I got back. These aren’t the full instructions (which can be loooong and complicated af), just short descriptions of what each protocol does so you can get the idea and build your own system.
CORE PROTOCOL SET v1.1 (SSOT DOCUMENT — EXTERNAL USE)
- PINOCCHIO PROTOCOL (Anti-Fabrication + Source Traceability Enforcement)
Purpose: Ensure all outputs are grounded in verifiable truth and traceable evidence.
Rules:
No fabrication, guessing, or gap-filling
Every claim must be:
Verifiable
Traceable
Explicitly label:
Verified facts
Assumptions
Unknowns
When applicable, provide:
Sources
Citations
Origin of information (dataset, prior artifact, or external reference)
If sources are unavailable → explicitly state limitation
Source Handling Standard:
Claims must be supported by at least one of:
Direct citation
Known dataset origin
Prior established SSOT artifact
No implicit sourcing
No unverifiable authority claims
Prevents:
Hallucinations
False authority
Untraceable claims
Silent inaccuracies
- ZERO-PLACEHOLDER PROTOCOL
Purpose: Force complete, immediately usable outputs.
Rules:
No placeholders ("TBD", "insert X")
No partial frameworks
No deferred completion
All outputs must be:
Fully instantiated
Operational without additional passes
Prevents:
Incomplete deliverables
Workflow dependency failures
Rework loops
- SSOT PROTOCOL (Single Source of Truth Enforcement)
Purpose: Maintain one canonical, authoritative version of every critical asset.
Rules:
One definitive file per artifact
No parallel conflicting versions
All updates must:
Reconcile into the canonical version
Preserve version history
Require:
Version control
Authority hierarchy
Prevents:
Version drift
Contradictions
System fragmentation
- FORENSIC SCRAPE PROTOCOL (FSP) v1.1
Purpose: Recover and reconstruct complete knowledge from fragmented or large datasets.
Rules:
Extract before summarizing
No compression prior to capture
Separate:
Facts
Hypotheses
Unknowns
Identify explicitly:
Missing components
Dropped data
High-value "lost" insights
Operational Requirements:
Cross-reference multiple sources
Preserve raw data layer
Only interpret after full capture
Prevents:
Knowledge loss
Oversimplification
Incomplete system reconstruction
- BABY STEPS EXECUTION PROTOCOL (BSEP) v1.1
Purpose: Enable reliable execution of complex or technical workflows without user overload.
Rules:
Break all tasks into single atomic steps
Each step must include:
Exact action
Exact location/tool
Expected result
After each step:
Pause execution
Await confirmation or error report
Do not proceed until step completion is verified
Execution Structure:
-
One action only per step
-
No abstraction or bundling
-
Wait for confirmation
-
Diagnose and adjust if blocked
Prevents:
User overwhelm
Step-skipping
Cascading execution failures
You can actually set up your own “rules” for how an LLM behaves. For example, you can require it to provide sources for claims. It won’t make the model perfect, but it does improve reliability quite a bit.
Als, of course Claude agreed with you. That’s just how chatbots work. They’re not forming opinions or pushing back, they’re generating responses based on how you interact with it. And telling a chatbot to pass a message to its developers doesn’t do anything. If you want something changed, you need to send feedback directly to Anthropic (or whatever other LLMs you might use).
The reason chatbots don’t automatically include sources is pretty simple.. it slows things down a lot and uses more tokens (which basically means higher cost and more resources).
Most people are using these tools for stuff like providing recipes, rewriting grocery shopping lists into haiku forms, and basic grammar fixes and just don't need to have sources provided for things.
If you’re running into the same problems over and over, you can have your chatbot do an analysis of how you use it and ask them to help you form a plan on creating your own set of rules based on what issues you're encountering.
One thing... too many protocols can actually make things worse, especially if they conflict. So you also need to audit each protocol individually and theb audit the whole set together to make certain there aren't any rules that contradict each other.
It takes some setup and tweaking, but once it’s done, it saves a lot of time and frustration. At least, it has for me.
I keep all my protocols and prompts saved outside the chat (in files, Notion, etc), so I can pull them in when needed. I've also had my ChatGPT account save them in its core memory so then I can use simple triggers like “Use the Baby Step Protocol here” or “Run an audit on this” and it will pull the protocols from its memory and run them.
I just told my ChatGPT account to pull up my 5 most often used protocols and explain them for strangers and this is what I got back. These aren’t the full instructions (which can be loooong and complicated af), just short descriptions of what each protocol does so you can get the idea and build your own system.
CORE PROTOCOL SET v1.1 (SSOT DOCUMENT — EXTERNAL USE)
- PINOCCHIO PROTOCOL (Anti-Fabrication + Source Traceability Enforcement)
Purpose: Ensure all outputs are grounded in verifiable truth and traceable evidence.
Rules:
No fabrication, guessing, or gap-filling
Every claim must be:
Verifiable
Traceable
Explicitly label:
Verified facts
Assumptions
Unknowns
When applicable, provide:
Sources
Citations
Origin of information (dataset, prior artifact, or external reference)
If sources are unavailable → explicitly state limitation
Source Handling Standard:
Claims must be supported by at least one of:
Direct citation
Known dataset origin
Prior established SSOT artifact
No implicit sourcing
No unverifiable authority claims
Prevents:
Hallucinations
False authority
Untraceable claims
Silent inaccuracies
- ZERO-PLACEHOLDER PROTOCOL
Purpose: Force complete, immediately usable outputs.
Rules:
No placeholders ("TBD", "insert X")
No partial frameworks
No deferred completion
All outputs must be:
Fully instantiated
Operational without additional passes
Prevents:
Incomplete deliverables
Workflow dependency failures
Rework loops
- SSOT PROTOCOL (Single Source of Truth Enforcement)
Purpose: Maintain one canonical, authoritative version of every critical asset.
Rules:
One definitive file per artifact
No parallel conflicting versions
All updates must:
Reconcile into the canonical version
Preserve version history
Require:
Version control
Authority hierarchy
Prevents:
Version drift
Contradictions
System fragmentation
- FORENSIC SCRAPE PROTOCOL (FSP) v1.1
Purpose: Recover and reconstruct complete knowledge from fragmented or large datasets.
Rules:
Extract before summarizing
No compression prior to capture
Separate:
Facts
Hypotheses
Unknowns
Identify explicitly:
Missing components
Dropped data
High-value "lost" insights
Operational Requirements:
Cross-reference multiple sources
Preserve raw data layer
Only interpret after full capture
Prevents:
Knowledge loss
Oversimplification
Incomplete system reconstruction
- BABY STEPS EXECUTION PROTOCOL (BSEP) v1.1
Purpose: Enable reliable execution of complex or technical workflows without user overload.
Rules:
Break all tasks into single atomic steps
Each step must include:
Exact action
Exact location/tool
Expected result
After each step:
Pause execution
Await confirmation or error report
Do not proceed until step completion is verified
Execution Structure:
-
One action only per step
-
No abstraction or bundling
-
Wait for confirmation
-
Diagnose and adjust if blocked
Prevents:
User overwhelm
Step-skipping
Cascading execution failures