Yeti Drive: 250 MB of File Context That Changes ServiceNow Drafting

Why Drafting in a Vacuum Produces Wrong Answers

Every ServiceNow developer has done it: paste a paragraph from a stakeholder email into a chat window, hope the model fills in the gaps, then spend the next hour rewriting the draft because it missed the field names, the parent business service, or the ITIL category your organisation actually uses.

The problem is not the model. The problem is context. A general-purpose LLM does not know your custom u_change_window table, your renamed Assignment Group structure, or that the "Priority Matrix" spreadsheet sitting in your inbox is the source of truth for incident routing.

Yeti Drive solves this by giving every SnowCoder user 250 MB of secure, encrypted file storage that Yeti AI Chat can reach into mid-conversation. Drop your spec PDFs, table exports, architecture diagrams, or screenshots into Yeti Drive once, and every subsequent prompt can ground itself in that material.

What 250 MB of Yeti Drive Actually Holds

250 MB sounds modest until you measure it against the artifacts ServiceNow developers actually work with. The vast majority of useful input is text-shaped: requirements documents, table dictionary exports, scoped application manifests, Update Set XML, ATF results, security audit findings.

A practical Yeti Drive at full capacity might hold the following:

• A 60-page Functional Design Document as PDF (around 4 MB)
• The full sys_dictionary export for your custom application (8 MB)
• Three Update Set XML exports for the last release (12 MB)
• Recent ATF test results, JSON formatted (2 MB)
• Wireframes and Figma exports for new Service Portal widgets (40 MB)
• Stakeholder Loom transcripts and Confluence exports (10 MB)
• Excel files mapping legacy ticket categories to new ServiceNow categories (3 MB)

That leaves more than 150 MB of headroom. The point is not raw volume. It is that one drive comfortably holds an entire epic's worth of source material, available to every conversation you start.

How Yeti AI Chat Uses Drive Files

Files in Yeti Drive are not auto-injected into every prompt. They are referenceable. You attach the files you want a particular conversation to draw on, and the model treats them as grounded context alongside its core ServiceNow knowledge base of 100,000+ vectors and 17,000+ code examples.

In practice, a session looks like this:

Conversation: New Asset Onboarding Flow
Mode: Architect hat, Thinking mode
Attached from Yeti Drive:
  - asset_onboarding_FDD_v3.pdf
  - cmdb_ci_hardware_dictionary.xlsx
  - existing_workflow_export.xml

Prompt: "Draft a Flow Designer flow that matches the
steps in section 4.2 of the FDD, using the field names
defined in the dictionary export. Do not invent fields."

Because the file content is grounded, the model now writes against your dictionary instead of guessing at OOB field names. The output respects your custom u_ prefixes, picks the right reference field types, and quotes the FDD section it derived each step from.

This is also why SnowCoder benchmarks 60% more accurate than generic LLMs across 120+ ServiceNow tests. The combination of a domain-tuned knowledge base and your own private drive context closes the gap that generic models cannot.

Security: What Sits Inside a Yeti Drive

Files in Yeti Drive are subject to the same safeguards that protect the rest of your SnowCoder data:

• AES-256-GCM encryption at rest, with a per-record salt and PBKDF2 key derivation using 100,000 iterations
• TLS 1.3 in transit on every upload, download, and inference call
• OAuth 2.1 with PKCE for the authorising session, with refresh-token rotation and replay-attack detection
• Per-tenant isolation, so your drive is never accessible to another customer's workspace
• Enterprise and Enterprise+ customers can pin the drive to data residency in the AWS region of their choice (any EU region available)

These controls map directly to the ISO 27001:2022 Annex A controls SnowCoder aligns to (currently 73 of 93, with the ISMS in progress and a target of Q4 2026 for certification), and feed into the SOC 2 Type II evidence base targeted for Q3 2026. You can review the full posture on the security page.

Patterns That Pay Off Inside Yeti Drive

Not every file is equally useful. The teams getting the strongest results from Yeti Drive treat it as a curated context library, not a junk drawer.

1. Dictionary Exports First

The single highest-value file you can put in Yeti Drive is a fresh export of sys_dictionary scoped to the tables your project touches. It eliminates an entire class of hallucinated field references and makes every generated GlideRecord query land on real columns.

2. The Glossary File

A one-page Markdown file that defines your organisation's acronyms, role names, and approval routing terminology. This single artifact reshapes generated acceptance criteria and notification copy to match your in-house voice.

3. The Approved Patterns Folder

Drop in three or four Script Includes that represent your team's house style. Yeti AI Chat under the Sr Dev hat will mirror naming conventions, error-handling patterns, and logging strategies from those examples when drafting new code.

4. Previous Update Sets

When iterating on a feature, attaching the prior Update Set XML lets the model reason about what already exists in the target instance, so its proposed changes are additive rather than duplicative.

When Yeti Drive Hands Off to Yeti Build Agent

Drive is part of Yeti AI Chat - the human lane. Once you have a tight, grounded conversation that turns the spec into a clean backlog, that backlog can be promoted to Yeti Build Agent, which delivers the 291-story build benchmark using 42 artifact classes via the ServiceNow Fluent SDK.

The boundary is deliberate. Humans iterate in Yeti with full file context. Agents execute on schedule against a vetted backlog. The two lanes never share keystrokes, which is one of the four commercial safeguards documented on the enterprise security page.

Related reading