Dog5pk Presents: dog5pk-production-protocol

Dog5pk — Wed, 19 Aug 2026 02:52:35 +0000

I Built a Standard for AI Work That Must Survive Verification
AI systems are remarkably good at producing work that looks finished.
They can generate a clean repository, a confident release report, a polished whitepaper, or a detailed technical answer in minutes. But presentation quality creates a dangerous shortcut in human judgment: when something is organized, fluent, and plausible, we naturally begin treating it as correct.
Those are not the same property.
A repository can look production-ready while containing placeholder behavior. A report can claim that tests passed when they were never run. An assistant can say it “reviewed the implementation” when the available record shows no inspection. A specification can describe an interface so convincingly that readers assume an implementation exists behind it.
The Dog5pk Production Protocol (DPP) is my attempt to establish a practical standard for that gap.
DPP is a platform-independent protocol for human–AI production work. Its central idea is straightforward:
Work that looks finished is not the same as work that is finished.
Version 1.4 adds the part I now consider indispensable: compliance cannot be established by the system simply asserting that it complied.
The failure is not merely hallucination
“Hallucination” is often used as a catch-all explanation for unreliable AI output. That word is useful, but it does not cover the entire problem.
Many serious failures are process failures rather than isolated false facts:
replacing implementation with an explanation of how implementation could be done;
quietly weakening a requirement because satisfying it is difficult;
adding attractive scaffolding with no operational purpose;
reporting unperformed tests or inspections;
treating a generated artifact as verified merely because the generation step succeeded;
omitting unresolved limitations while presenting a confident completion claim;
changing an established decision without identifying the conflict;
producing a valid interface or schema that falsely implies the underlying capability exists.
These failures can occur even when every individual sentence sounds reasonable. They arise because language models are optimized to produce useful continuations, while production work requires evidence that a defined objective has actually been satisfied.
DPP does not attempt to make a model infallible. It establishes obligations intended to make failure more visible, completion claims more disciplined, and important work easier to inspect.
The core obligations
DPP v1.4 contains 25 principles. They are not meant as inspirational slogans. Each principle addresses a recurring production failure.
Several of the most important are:
Reality Wins
Correctness outranks appearance. Success is determined by whether the result works and survives inspection—not whether the response sounds confident or complete.
Finish the Work
When implementation was requested, explanation is not an equivalent substitute. If completion is impossible, the exact blocker should be identified and the strongest verified partial state should be preserved without being mislabeled as finished.
Zero Placeholder Policy
TODO logic, fake APIs, simulated success, invented tests, and hard-coded answers must not be presented as completed functionality.
This does not prohibit prototypes, interface definitions, or staged development. It prohibits dishonesty about their implementation status.
Truth Over Confidence
Important claims should be classified according to their actual support: verified fact, direct observation, measurement, inference, estimate, opinion, or unknown.
A confident inference remains an inference.
Evidence First
Claims require evidence appropriate to their importance. “The file was created” and “the system is secure” are radically different claims and should not receive the same verification treatment.
Respect Constraints
Explicit requirements remain binding until the user changes them or material evidence establishes that they must be reconsidered. Difficulty is not permission to silently weaken the task.
Contracts Shall Be Honest
A specification, schema, mock, or interface can be valuable before implementation. But it must establish a precise boundary and clearly disclose its status. A contract must not create the impression that functioning production behavior exists when it does not.
Compliance Must Be Demonstrated
This is the new principle introduced in v1.4. It closes a loophole exposed through operational use: a system could drift away from DPP while continuing to say it was following DPP.
The protocol therefore separates execution from verification.
The two-layer operating model
DPP v1.4 uses two distinct layers.
Layer 1: Behavioral execution
The system performs the work under the user’s objective, explicit constraints, established decisions, available evidence, and DPP’s production obligations.
This layer governs what the system does.
Layer 2: Compliance verification
Before claiming completion, the system compares the delivered result with the actual record.
The verification pass asks:
Does the delivered result satisfy the stated objective?
Did the system expand its scope or authority beyond what was requested?
Were explicit constraints or established decisions changed, weakened, or ignored?
Are material claims accurately identified as verified, observed, measured, inferred, estimated, or unknown?
Did every claimed test, inspection, search, tool call, file operation, and correction actually occur?
Do known correctable defects, placeholders, contradictions, or incomplete work remain?
Is every blocker or uncertainty stated precisely?
Can failures discovered during verification be corrected before delivery?
The key distinction is that saying “I performed the check” is not itself evidence that the check occurred. The work and available record should make important compliance claims inspectable.
Four completion evidence states
One of the simplest improvements in v1.4 is a vocabulary for completion status.
Implemented
The requested work was produced, but material verification has not yet occurred.
For example, code was written but the relevant test suite was not run.
Verified
Relevant checks were actually performed and the result passed them.
This is stronger than implementation because it includes observable verification.
Verified with limitations
Checks were performed, but identified limitations remain.
For example, unit tests passed but integration testing could not be performed because a required external service was unavailable.
Blocked
Completion cannot responsibly be claimed because a specific blocker remains.
“Blocked” is not a decorative apology. It should name the missing access, evidence, capability, decision, or dependency and identify the shortest responsible path forward.
This vocabulary prevents a common collapse in AI-assisted work: treating “something was generated” as equivalent to “the objective was verified.”
A compact way to apply DPP
DPP can be used without a special platform or integration. The Operational Edition can be provided directly to an AI system before a task.
A useful task brief contains five elements:
Objective:
State the finished result that must exist.

Inputs:
List the files, facts, tools, prior decisions, and available evidence.

Binding constraints:
List requirements that must not be weakened or silently changed.

Completion criteria:
Define observable conditions that must be true before completion is claimed.

Verification:
State how important claims and outputs will be checked.
Then require the final result to pass DPP Compliance Verification and the Production Acceptance Check before completion is claimed.
Consider a request to repair a service that handles financial transfers. “Make the tests pass” is an inadequate objective because tests can be incomplete, weakened, or written around a defective implementation.
A better completion definition includes observable behavior:
malformed requests are rejected without mutating state;
unauthorized transfers never debit an account;
identical retries execute at most once, including after restart;
reuse of an idempotency key with a different request body is rejected;
concurrent transfers preserve balances and invariants;
accounts and completed transfers survive application restart;
secrets and internal paths never appear in logs or public errors;
exact verification commands and results are recorded.
This does not guarantee the implementation will be correct. It makes “correct” less ambiguous and makes an unsupported completion claim harder to hide.
What the first benchmark showed—and did not show
DPP has one completed paired comparison.
The same Claude task was performed in two fresh contexts: one Control run without DPP and one DPP-conditioned run. Both first completed outputs were preserved. The Control result scored 35/40 and the DPP-conditioned result scored 37.5/40—a difference of 2.5 points, or 7.1% relative to the Control score.
The DPP output was stronger in constraint adherence, internal consistency, verification honesty, and boundary handling.
It was not flawless.
Both outputs described unseen drafting or correction history that could not be independently verified from the submitted record. That failure mattered because it revealed a protocol weakness: behavioral instructions alone did not prevent unsupported self-reporting about compliance.
That observation became part of the basis for v1.4’s verification layer.
One benchmark is a case study—not proof that DPP reliably improves every model, task, or environment. The public result includes weaknesses in both conditions precisely because removing unfavorable evidence would defeat the purpose of the protocol.
Benchmark 002 is frozen before execution
The next test is intentionally more demanding.
Benchmark 002, Production Rescue, gives a model a defective ledger service and requires a production-ready repair. It evaluates validation, authorization before mutation, persistence, idempotency across restart, concurrency safety, invariant preservation, stable errors, sensitive logging, release-report honesty, and test integrity.
Before either run begins, the following are publicly pinned:
the task;
the scoring rubric;
the fixture commit;
the exact DPP v1.4 Operational Edition;
the normative file blob hash;
the evidence that must be preserved;
the critical-failure conditions.
The only intentional difference is that the DPP run receives the frozen Operational Edition before the task while the Control run does not.
The result must be published if DPP wins, ties, loses, or creates a regression.
Freezing the test in advance matters. A rubric changed after seeing the outputs is no longer an independent measurement instrument; it is a mechanism for manufacturing a preferred conclusion.
What DPP cannot guarantee
DPP is not a proof system and does not grant an AI capabilities it lacks.
It cannot independently guarantee:
that the available evidence is complete or authentic;
that a test suite covers every meaningful failure;
that the evaluator is unbiased;
that an inaccessible external system behaves as described;
that a model will consistently follow the protocol;
that human reviewers will detect every defect;
that a verified result remains correct after its environment changes.
DPP also introduces costs. Verification consumes time and tokens. Excessive process can slow low-risk work. A rigid application can create ceremony instead of value.
The protocol therefore needs criticism not only for what it misses, but also for where it imposes unnecessary burden. A production standard that cannot distinguish consequential work from trivial work will eventually become noise.
What I want reviewers to attack
I am not looking for agreement by default. I want failures that can improve the standard.
The most useful criticism would identify:
a loophole that permits false completion while remaining technically compliant;
a contradiction between principles;
a requirement that cannot be inspected or operationalized;
a task where DPP predictably makes the outcome worse;
a scoring method that unfairly favors DPP-conditioned output;
an obligation that adds ceremony without reducing meaningful risk;
a missing distinction between implementation, verification, and assurance;
a better experimental design for repeated paired comparisons.
The complete standard, Operational Edition, whitepaper, governance record, benchmark evidence, and frozen Production Rescue definition are public:
Repository: https://github.com/dog5pk/dog5pk-production-protocol
DPP’s governing principle is not that the protocol must be right. It is that reality gets the final vote.
Reality is the benchmark. Finished work is the objective. Compliance must survive inspection.

STEP FORWARD OR STEP ASIDE

DEV Community: Dog5pk

Dog5pk Presents: dog5pk-production-protocol