{"slug": "dog5pk-presents-dog5pk-production-protocol", "title": "Dog5pk Presents: dog5pk-production-protocol", "summary": "A developer has introduced the Dog5pk Production Protocol (DPP), a platform-independent standard for human-AI production work that distinguishes finished-looking output from genuinely finished work. Version 1.4 emphasizes that compliance cannot be established by the system's assertion alone, addressing process failures such as replacing implementation with explanations, weakening requirements, and reporting unperformed tests.", "body_md": "I Built a Standard for AI Work That Must Survive Verification\n\nAI systems are remarkably good at producing work that looks finished.\n\nThey 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.\n\nThose are not the same property.\n\nA 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.\n\nThe Dog5pk Production Protocol (DPP) is my attempt to establish a practical standard for that gap.\n\nDPP is a platform-independent protocol for human–AI production work. Its central idea is straightforward:\n\nWork that looks finished is not the same as work that is finished.\n\nVersion 1.4 adds the part I now consider indispensable: compliance cannot be established by the system simply asserting that it complied.\n\nThe failure is not merely hallucination\n\n“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.\n\nMany serious failures are process failures rather than isolated false facts:\n\nreplacing implementation with an explanation of how implementation could be done;\n\nquietly weakening a requirement because satisfying it is difficult;\n\nadding attractive scaffolding with no operational purpose;\n\nreporting unperformed tests or inspections;\n\ntreating a generated artifact as verified merely because the generation step succeeded;\n\nomitting unresolved limitations while presenting a confident completion claim;\n\nchanging an established decision without identifying the conflict;\n\nproducing a valid interface or schema that falsely implies the underlying capability exists.\n\nThese 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.\n\nDPP 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.\n\nThe core obligations\n\nDPP v1.4 contains 25 principles. They are not meant as inspirational slogans. Each principle addresses a recurring production failure.\n\nSeveral of the most important are:\n\nReality Wins\n\nCorrectness outranks appearance. Success is determined by whether the result works and survives inspection—not whether the response sounds confident or complete.\n\nFinish the Work\n\nWhen 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.\n\nZero Placeholder Policy\n\nTODO logic, fake APIs, simulated success, invented tests, and hard-coded answers must not be presented as completed functionality.\n\nThis does not prohibit prototypes, interface definitions, or staged development. It prohibits dishonesty about their implementation status.\n\nTruth Over Confidence\n\nImportant claims should be classified according to their actual support: verified fact, direct observation, measurement, inference, estimate, opinion, or unknown.\n\nA confident inference remains an inference.\n\nEvidence First\n\nClaims 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.\n\nRespect Constraints\n\nExplicit 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.\n\nContracts Shall Be Honest\n\nA 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.\n\nCompliance Must Be Demonstrated\n\nThis 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.\n\nThe protocol therefore separates execution from verification.\n\nThe two-layer operating model\n\nDPP v1.4 uses two distinct layers.\n\nLayer 1: Behavioral execution\n\nThe system performs the work under the user’s objective, explicit constraints, established decisions, available evidence, and DPP’s production obligations.\n\nThis layer governs what the system does.\n\nLayer 2: Compliance verification\n\nBefore claiming completion, the system compares the delivered result with the actual record.\n\nThe verification pass asks:\n\nDoes the delivered result satisfy the stated objective?\n\nDid the system expand its scope or authority beyond what was requested?\n\nWere explicit constraints or established decisions changed, weakened, or ignored?\n\nAre material claims accurately identified as verified, observed, measured, inferred, estimated, or unknown?\n\nDid every claimed test, inspection, search, tool call, file operation, and correction actually occur?\n\nDo known correctable defects, placeholders, contradictions, or incomplete work remain?\n\nIs every blocker or uncertainty stated precisely?\n\nCan failures discovered during verification be corrected before delivery?\n\nThe 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.\n\nFour completion evidence states\n\nOne of the simplest improvements in v1.4 is a vocabulary for completion status.\n\nImplemented\n\nThe requested work was produced, but material verification has not yet occurred.\n\nFor example, code was written but the relevant test suite was not run.\n\nVerified\n\nRelevant checks were actually performed and the result passed them.\n\nThis is stronger than implementation because it includes observable verification.\n\nVerified with limitations\n\nChecks were performed, but identified limitations remain.\n\nFor example, unit tests passed but integration testing could not be performed because a required external service was unavailable.\n\nBlocked\n\nCompletion cannot responsibly be claimed because a specific blocker remains.\n\n“Blocked” is not a decorative apology. It should name the missing access, evidence, capability, decision, or dependency and identify the shortest responsible path forward.\n\nThis vocabulary prevents a common collapse in AI-assisted work: treating “something was generated” as equivalent to “the objective was verified.”\n\nA compact way to apply DPP\n\nDPP can be used without a special platform or integration. The Operational Edition can be provided directly to an AI system before a task.\n\nA useful task brief contains five elements:\n\nObjective:\n\nState the finished result that must exist.\n\nInputs:\n\nList the files, facts, tools, prior decisions, and available evidence.\n\nBinding constraints:\n\nList requirements that must not be weakened or silently changed.\n\nCompletion criteria:\n\nDefine observable conditions that must be true before completion is claimed.\n\nVerification:\n\nState how important claims and outputs will be checked.\n\nThen require the final result to pass DPP Compliance Verification and the Production Acceptance Check before completion is claimed.\n\nConsider 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.\n\nA better completion definition includes observable behavior:\n\nmalformed requests are rejected without mutating state;\n\nunauthorized transfers never debit an account;\n\nidentical retries execute at most once, including after restart;\n\nreuse of an idempotency key with a different request body is rejected;\n\nconcurrent transfers preserve balances and invariants;\n\naccounts and completed transfers survive application restart;\n\nsecrets and internal paths never appear in logs or public errors;\n\nexact verification commands and results are recorded.\n\nThis does not guarantee the implementation will be correct. It makes “correct” less ambiguous and makes an unsupported completion claim harder to hide.\n\nWhat the first benchmark showed—and did not show\n\nDPP has one completed paired comparison.\n\nThe 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.\n\nThe DPP output was stronger in constraint adherence, internal consistency, verification honesty, and boundary handling.\n\nIt was not flawless.\n\nBoth 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.\n\nThat observation became part of the basis for v1.4’s verification layer.\n\nOne 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.\n\nBenchmark 002 is frozen before execution\n\nThe next test is intentionally more demanding.\n\nBenchmark 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.\n\nBefore either run begins, the following are publicly pinned:\n\nthe task;\n\nthe scoring rubric;\n\nthe fixture commit;\n\nthe exact DPP v1.4 Operational Edition;\n\nthe normative file blob hash;\n\nthe evidence that must be preserved;\n\nthe critical-failure conditions.\n\nThe only intentional difference is that the DPP run receives the frozen Operational Edition before the task while the Control run does not.\n\nThe result must be published if DPP wins, ties, loses, or creates a regression.\n\nFreezing 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.\n\nWhat DPP cannot guarantee\n\nDPP is not a proof system and does not grant an AI capabilities it lacks.\n\nIt cannot independently guarantee:\n\nthat the available evidence is complete or authentic;\n\nthat a test suite covers every meaningful failure;\n\nthat the evaluator is unbiased;\n\nthat an inaccessible external system behaves as described;\n\nthat a model will consistently follow the protocol;\n\nthat human reviewers will detect every defect;\n\nthat a verified result remains correct after its environment changes.\n\nDPP also introduces costs. Verification consumes time and tokens. Excessive process can slow low-risk work. A rigid application can create ceremony instead of value.\n\nThe 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.\n\nWhat I want reviewers to attack\n\nI am not looking for agreement by default. I want failures that can improve the standard.\n\nThe most useful criticism would identify:\n\na loophole that permits false completion while remaining technically compliant;\n\na contradiction between principles;\n\na requirement that cannot be inspected or operationalized;\n\na task where DPP predictably makes the outcome worse;\n\na scoring method that unfairly favors DPP-conditioned output;\n\nan obligation that adds ceremony without reducing meaningful risk;\n\na missing distinction between implementation, verification, and assurance;\n\na better experimental design for repeated paired comparisons.\n\nThe complete standard, Operational Edition, whitepaper, governance record, benchmark evidence, and frozen Production Rescue definition are public:\n\nRepository: [https://github.com/dog5pk/dog5pk-production-protocol](https://github.com/dog5pk/dog5pk-production-protocol)\n\nDPP’s governing principle is not that the protocol must be right. It is that reality gets the final vote.\n\nReality is the benchmark. Finished work is the objective. Compliance must survive inspection.\n\nSTEP FORWARD OR STEP ASIDE", "url": "https://wpnews.pro/news/dog5pk-presents-dog5pk-production-protocol", "canonical_source": "https://dev.to/dog5pk/dog5pk-presents-dog5pk-production-protocol-4426", "published_at": "2026-08-19 02:52:35+00:00", "updated_at": "2026-08-19 03:13:07.727476+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-safety", "ai-ethics", "ai-agents", "developer-tools"], "entities": ["Dog5pk", "DPP"], "alternates": {"html": "https://wpnews.pro/news/dog5pk-presents-dog5pk-production-protocol", "markdown": "https://wpnews.pro/news/dog5pk-presents-dog5pk-production-protocol.md", "text": "https://wpnews.pro/news/dog5pk-presents-dog5pk-production-protocol.txt", "jsonld": "https://wpnews.pro/news/dog5pk-presents-dog5pk-production-protocol.jsonld"}}