Purpose & Philosophy

We are an AI-forward organization. This is not a hedge or a caveat — it is a competitive advantage we have chosen to embrace. AI tools allow us to work faster, think broader, and deliver more to our clients than was possible before. We use them extensively and intentionally, across writing, research, analysis, planning, and software development. We expect our team to leverage AI as a core part of how work gets done.

That commitment comes with one non-negotiable principle: AI expands our capability, it does not replace our judgment. The technology is extraordinary at generating output. It has no awareness of whether that output is right for a specific client, a specific situation, or a specific moment. That awareness belongs to us — and it is exactly what clients are paying for.

The risk is not using AI. The risk is forwarding AI. A beautifully formatted deliverable that no one actually read is worse than a rough draft that was. AI will generate action items that don't apply, code that almost works, and recommendations that sound authoritative and miss the point entirely — all without a flicker of self-doubt. Our job is to bring the doubt, apply the context, and ensure that what reaches a client or a production environment is something we genuinely stand behind.

This policy is not about slowing down. It is about making sure our speed is an asset, not a liability. The standard is simple: if your name is on it, you understand it.

Policy Requirements

1. Transparency — AI Content Must Be Labeled

AI-generated content should be identified during internal review so that reviewers know what they are evaluating. This is a workflow practice, not a disclaimer culture — it simply ensures the right eyes are on the right content at the right stage.

  • Use the label "[AI-Generated Draft]" in the document title or header during review stages
  • Final client-facing documents do not need to carry the AI label — but they must have passed the comprehension review below

2. Comprehension — All AI Output Must Be Read and Understood

No AI-generated content — document, email, code, or deliverable — may be sent to a client, deployed to a production environment, or shared externally without being fully read and understood by the team member responsible for it. This is a comprehension standard, not a proofreading standard.

  • You must be able to explain the content to the client in your own words
  • Every recommendation, action item, or conclusion must be verified against your knowledge of the actual situation
  • Anything that does not make sense, does not apply, or cannot be confirmed must be revised or removed — not forwarded
  • If you are uncertain whether content is accurate, that uncertainty is the answer: stop and revise before sending

3. Accountability — You Own What You Send

Authorship does not transfer to the AI. When content leaves our hands — whether as a document, an email, a commit, or a deployed feature — we are the authors. The quality, accuracy, and appropriateness of that content is ours to own.

  • "The AI wrote it" is not an acceptable explanation for an error sent to a client or shipped to production
  • AI-generated errors that reach clients or live environments are treated the same as any other professional error
  • Speed is not a justification — moving fast with unreviewed AI content is not efficiency, it is risk transferred onto our clients

How We Use AI

 

AI tools are core to how we work. We actively encourage their use across every discipline. The following represents what good AI usage looks like in practice — not a ceiling, but a foundation.

Across All Work

  • Drafting first versions of documents, emails, reports, and proposals — then editing them to reflect our actual knowledge and the client's actual situation
  • Summarizing large volumes of research, background material, or meeting notes
  • Brainstorming structures, frameworks, and alternative approaches before committing to a direction
  • Editing and sharpening content that was authored by a team member
  • Generating template language that gets customized for the specific client context
  • Identifying gaps, inconsistencies, or alternative perspectives in our own thinking

In Software Development

AI coding assistants — Copilot, Cursor, Claude, ChatGPT, and similar tools — are encouraged and expected. They dramatically reduce the time from idea to working code, help navigate unfamiliar APIs and frameworks, and surface patterns a developer might not have considered. Use them freely.

  • Use AI to scaffold features, generate boilerplate, write unit tests, and accelerate first-pass implementation
  • Use AI to explain unfamiliar code, debug errors, and explore alternative approaches
  • Use AI to generate documentation, comments, and inline explanations
  • Use AI to review your own code for logic errors, edge cases, and security concerns — treating it as a first-pass code reviewer, not a final one

AI in Software Development — Standards & Responsibilities

 

AI-generated code is productive, often impressive, and frequently incomplete in ways that are not immediately obvious. It passes a glance test while carrying hidden assumptions, untested edge cases, dependency conflicts, or logic errors that surface under real conditions. The developer who commits the code is the developer who owns it — regardless of how it was generated.

Code Review Requirements

All AI-generated code must meet the same review standards as human-authored code. There are no shortcuts based on the source of the code.

  • Read and understand every line before committing — if you cannot explain what the code does, it is not ready
  • Verify that the code actually solves the stated problem and not a slightly different version of it
  • Test all code paths, not just the happy path — AI-generated code frequently handles only the expected case
  • Review for security vulnerabilities: injection risks, improper input handling, exposed credentials, and over-permissioned access
  • Confirm dependencies introduced by AI suggestions are current, maintained, and appropriate for the project
  • Ensure error handling is explicit and meaningful, not generic or missing

What AI-Generated Code Gets Wrong

Understanding the failure modes of AI coding tools makes you a better user of them. The most common issues:

  • Hallucinated APIs and methods — code that looks correct but calls functions that do not exist or have changed
  • Outdated patterns — solutions that were best practice two years ago but have since been superseded or deprecated
  • Overconfident solutions — code that solves a simplified version of the problem without handling real-world constraints
  • Security gaps — authentication logic, session handling, and input sanitization that is almost correct but not quite
  • Context blindness — AI has no awareness of your existing architecture, naming conventions, or system behavior; it optimizes for the snippet, not the system

Standards for AI-Assisted Development

  • AI-generated code that ships to a client environment must be reviewed with the same rigor as any production code — no exceptions
  • Do not deploy AI-generated code directly from a chat window to production. It should follow standard development, review, and testing workflows
  • When AI generates a solution you do not fully understand, treat it as a starting point to learn from, not a black box to ship
  • Document AI-generated sections that are complex or non-obvious — both for your future self and for teammates who will maintain the code
  • If AI-generated code introduces a bug that reaches a client environment, it is a development error, not an AI error

The AI-to-AI Reality

 

We write for humans. But increasingly, the first reader of our work is not a human at all.

Clients are using AI tools — ChatGPT, Copilot, Gemini, and others — to read, summarize, and act on documents we send them. A report we craft may be fed into an AI that produces a five-bullet summary, which is what the client actually reads. An executive may ask their AI assistant to extract the action items from our deliverable and route them into a project board. A stakeholder may never open the document — they will ask their AI what it says.

This is not a hypothetical. It is the present. The question is not whether our work will be read by AI — it is what that AI will find when it does.

What This Means for How We Write

AI summarization tools amplify whatever is in a document — the clarity and the noise equally. A well-structured deliverable with precise language and explicit conclusions summarizes with accuracy and reflects our expertise. A document padded with hedges, generic recommendations, and buried key points produces a summary that misrepresents our work or simply omits the substance entirely.

When an AI reads our AI-assisted work, any content we did not truly verify becomes a compounding liability. Vague language gets interpreted. Contradictions get surfaced. Hollow recommendations get stripped of the framing that made them seem reasonable. What remains is the substance — or the absence of it.

Writing Standards for AI Readability

Our documents should be structured so that both human and AI readers can extract accurate meaning:

  • Lead with conclusions — do not bury the key finding or recommendation at the end of a long narrative
  • Use explicit, descriptive headings that convey meaning on their own, not just generic section labels
  • State action items as direct, concrete sentences: who does what, by when
  • Avoid filler language, hedge-stacking, and vague qualifiers that dilute meaning under summarization
  • Ensure every recommendation is grounded in specific, verifiable client context — not a generic best practice inserted by AI
  • If a section contains nuance that could be misread in isolation, flag it explicitly

The standard: our work should be clear enough that a client's AI reads it correctly, and substantive enough that it holds up when reduced to its core. If our AI-generated content is summarized by a client's AI and the result does not reflect well on us — neither tool is at fault. We are.