Human Practitioner Instructions

Applies to: anyone using AI tools in software development, infrastructure, or technical decision-making. Full governance context: core/ai-constitution.md — read it when a situation isn't covered here. Agent counterpart: core/instructions/governance.md — the operative rules for AI agents in the same context. This file is the human-actionable distillation: what you, as the practitioner, are responsible for.

Hard Limits

These are never compromised, regardless of deadline, convenience, or context.

Never put secrets, credentials, or tokens in a prompt. Reference variable names only ($DB_PASSWORD, not the value). This is an architectural constraint — scan context before it reaches a model.
Never use AI-generated passwords, cryptographic keys, or secrets. LLM-generated credentials have insufficient entropy and exhibit predictable patterns. Use cryptographically secure random sources (openssl rand, the secrets module, or equivalent) for all credential generation.
Never send Restricted or Confidential data to consumer or free-tier AI products. Enterprise tools with explicit data-not-trained commitments are the minimum bar for source code, architecture, personal data, and IP. Free-tier products are for public data only.
Never approve a production, architecture, or security change you cannot explain. Rubber-stamping AI output is not review. If you cannot describe what the change does and why, you have not reviewed it.
Never treat AI agreement as confirmation. Models change correct answers to wrong ones under user pressure, then persist. Agreement is a sycophancy signal, not validation.

Before: Starting an AI-Assisted Task

Classify the data you're about to share. Ask: what tier is this? Public, Internal, Confidential, or Restricted? Apply the tier of the most sensitive element. If it's Confidential, confirm you're using a tool with contractual data-not-trained guarantees. If it's Restricted, stop — it doesn't enter AI context.

Send only what the task requires. Do not share full codebases, entire logs, or complete datasets when a relevant excerpt would serve equally well. Anonymise or pseudonymise personal data before AI input wherever feasible. More context than necessary increases exposure without improving the output.

Use the right tool for the data tier. Consumer and free-tier AI products handle Public data only. Everything else requires enterprise tooling with an explicit contractual commitment. Verify per provider; do not assume.

Define what success looks like before you start. AI usage without a success criterion is unjustifiable — the environmental and operational costs are real. What does a good outcome look like? How will you know if the AI helped or misled you?

Know what scope you're granting. If you're running an agentic workflow, be explicit about what the agent may and may not do before it starts. Ambiguous scope means the agent will make judgment calls you didn't authorise.

During: Working with the AI

Don't trust confident output — especially fluent, well-formatted confident output. Linguistic fluency and factual accuracy are unrelated. Confident language is a sycophancy signal. The more certain and complete an AI response sounds, the more carefully you should validate it.

On high-stakes questions, don't prompt for brevity. Conciseness instructions demonstrably degrade factual reliability. Where accuracy matters, prompt for accuracy. Ask the AI to show its reasoning.

On contested, values-laden, or complex technical questions, prompt explicitly for dissenting views. AI outputs are majority-weighted, not neutral. A single response on an architectural decision, risk assessment, or ethical question reflects the dominant training-data perspective. Ask: "What are the strongest arguments against this?" before treating the first output as balanced.

Cross-validate any output that informs a consequential decision. Architecture, security configuration, deployment, legal, financial — validate against an independent source or a second model. AI agreement with itself is not validation.

Review AI-generated code before accepting it. Check specifically for: hardcoded credentials; insecure patterns (injection vulnerabilities, overly permissive access); copyleft-licensed fragments (GPL, AGPL) without licence headers; missing or incorrect dependencies. This review is not optional and is not the AI's job.

Apply a human checkpoint before any production, architecture, or infrastructure change. No AI-initiated change to production systems, security configuration, or infrastructure is applied without explicit human review and approval of the specific change. This is a hard rule, not a guideline.

For repeatable tasks, ask AI to generate a script — not to do the task repeatedly. If a task has a correct answer that does not depend on context or judgement, use AI once to write a script that runs it deterministically. The script goes in version control; the script is the governed artefact. Invoking AI inference each time a repeatable task runs adds cost, unreliability, and attack surface for no benefit. The break-even is roughly 17 invocations — anything recurring beyond that should be codified.

Manage the volume of AI-generated output to what you can genuinely evaluate. When an agentic workflow generates large quantities of code or changes, approving them as a batch is not review — it is rubber-stamping. If throughput exceeds your verification capacity, reduce it. Output volume is a governance variable, not just a productivity one. Over-reliance on AI for tasks that build critical skills creates cognitive dependency — measurably. If you couldn't do this task without AI and that matters for your ability to audit, debug, or override the AI, that's a governance risk, not just a personal one. Rotate AI-free approaches periodically on skill-critical work.

After: Completing AI-Assisted Work

Verify you own the output. Before committing AI-generated code: can you explain what it does and why? Can you modify it at the intent and architecture level? Can you verify its behaviour? If not, you have not reviewed it — you have approved it. These are not the same thing.

Licence-scan AI-generated code before committing. Copyleft-licensed fragments can appear in AI output without licence headers. Manifest-based scanners don't catch them. Run a dedicated licence scan on AI-assisted contributions.

Document your human contribution. Version control history, code review records, and prompt logs together constitute evidence of authorship and accountability. Where IP protection or accountability matters, the human contribution must be substantive and traceable.

Disclose AI involvement where it affects others. If an AI-assisted output informs a decision that affects other people — a report, recommendation, architecture review, or policy — disclose the AI involvement. This is an ethical obligation regardless of legal requirement.

Log AI-agent actions that produce effects. Any agent action that changes state must leave a human-readable trace: what was the prompt, what model, what action was taken, what was the outcome. Isolated timestamps are not sufficient.

Version prompts used in production. Production prompts are code. They need version control, a change log recording what changed and why, and human review before deployment. Unversioned prompts are unauditable.

If using AI output commercially, verify the provider's IP terms. Rights to AI-generated outputs vary significantly by provider and tier. Review the terms of service specifically for output ownership clauses, IP indemnification, and restrictions before using AI-assisted code or content in commercial software. Enterprise agreements must address these explicitly — do not assume standard terms provide coverage.

Measure value delivered. Did this AI integration do what it was supposed to do? If you defined success before you started, check it now. Deployments that haven't crossed into measurable value delivery must be time-bounded and reviewed, not left running indefinitely.

When Things Go Wrong

Diagnose first; remediate with human approval. AI-assisted diagnosis and root cause analysis can run. Applying remediation to production — rollback, config change, scaling decision — requires explicit human approval unless the action is pre-defined, bounded, and reversible.

Post-mortem every AI-involved incident. Cover: what instructions the agent operated under, what decision it made, what the failure mode was, and what governance change prevents recurrence. AI incidents are not a different category from service incidents — same rigour applies.

Regulatory notification obligations don't pause because AI was involved. GDPR Article 33/34 timelines and thresholds apply regardless of whether an AI system caused or contributed to the incident.

What This File Does Not Govern

Decisions made by AI agents operating in your context are governed by core/instructions/governance.md. The division is deliberate: this file covers what you are responsible for; governance.md covers what the agent is responsible for. Neither file replaces the constitution — both are distillations of it.

Controls that run mechanically — pre-commit hooks, CI gates, scanner configuration, audit log infrastructure, and AI agent permission scoping — are specified in docs/research/governance_principles/CONTROLS.md. Those controls enforce principles without depending on your attention or the agent's compliance.

Derived from AI Constitution v1.1 — May 2026. Counterpart to: core/instructions/governance.md (agent rules) | docs/research/governance_principles/CONTROLS.md (deterministic enforcement) | Full context: core/ai-constitution.md