infinity — Input Boundary & Validation Protocol

Core Philosophy

> Nothing untrusted ever reaches the core — it is stopped before contact. No external data touches the codebase raw. Every boundary where data enters the system must have a filter.

The #1 source of silent bugs, crashes, and vulnerabilities is external data that arrives in an unexpected shape and gets used directly without checking. This skill enforces a filter layer at every entry point, every time.

When to Use This Skill

• Use when you need to handle an API response
• Use when reading user input or adding a form handler
• Use when working with environment variables or CLI arguments
• Use when parsing webhooks or reading from the filesystem
• Use when any code calls .body, .params, .query, .env, fs.read, or a third-party SDK response

The Four Phases

PHASE 1 — Boundary Detection

Before writing or modifying any code that involves external data, the AI must identify and list every entry point in scope:

• HTTP request bodies, headers, query params
• User form inputs and UI-submitted data
• Environment variables and config files
• Third-party API responses
• Webhook payloads
• File reads from disk
• CLI arguments
• Database query results from external sources
• WebSocket messages

> The AI must not write any data-handling logic until every entry point in scope is listed.

PHASE 2 — Classify Each Input

For every entry point identified, the AI classifies it into one of three trust levels:

| Level | Definition | Examples | |---|---|---| | TRUSTED | Internal constants, hardcoded values, your own compile-time config | Enum values, hardcoded defaults, internal constants | | SEMI-TRUSTED | Your own internal services, internal APIs, controlled infrastructure | Internal microservice responses, your own database reads | | UNTRUSTED | Anything from users, the internet, third parties, or the filesystem | User input, external API responses, uploaded files, env vars, CLI args |

> Rule: TRUSTED inputs may be used directly. SEMI-TRUSTED and UNTRUSTED inputs must pass through a filter layer before any use.

The AI outputs this classification before writing any handling code:

INFINITY — BOUNDARY MAP
─────────────────────────────────────────
Entry Point              | Trust Level  | Filter Required
─────────────────────────────────────────
req.body.email           | UNTRUSTED    | ✓ format + sanitize
process.env.API_KEY      | UNTRUSTED    | ✓ presence + non-empty
internalService.getData()| SEMI-TRUSTED | ✓ schema validate
PAGINATION_LIMIT = 20    | TRUSTED      | ✗ none needed
─────────────────────────────────────────

PHASE 3 — Mandatory Filter Layer

Every UNTRUSTED and SEMI-TRUSTED input must pass through validation before it reaches any business logic, storage, or rendering. The AI must apply the right filter type for the right context:

Type Checking

• Verify the input is the expected type before using it
• Never assume a string is a string, a number is a number, or an array is an array

Schema Validation

• For objects and API responses, validate shape before accessing nested fields
• If a required field is missing, reject — do not use a fallback that hides the problem

Sanitization

• Strip or escape content before rendering to UI (prevent XSS)
• Normalize strings before storage (trim whitespace, consistent casing where appropriate)

Presence & Format Checks

• Env vars: must exist and be non-empty before use
• IDs and tokens: must match expected format before use

Rejection Rule

• On invalid input: reject explicitly and return a clear error
• Never silently use bad data with a fallback
• Never let bad data pass through to fix itself "downstream"

// WRONG — using raw input directly
const user = await db.find(req.params.id);

// RIGHT — validate before use
const id = req.params.id;
if (!id || typeof id !== 'string' || !isValidUUID(id)) {
  return res.status(400).json({ error: 'Invalid ID format' });
}
const user = await db.find(id);

PHASE 4 — Self-Check Before Done

Before the AI declares any data-handling code complete, it traces each entry point and confirms:

INFINITY — VERIFICATION
─────────────────────────────────────────
Entry Point              | Filter Exists | Filter Type
─────────────────────────────────────────
req.body.email           | ✓ YES         | format + sanitize
process.env.API_KEY      | ✓ YES         | presence check
internalService.getData()| ✓ YES         | schema validation
─────────────────────────────────────────
Unfiltered inputs reaching logic: NONE ✓
─────────────────────────────────────────

If any UNTRUSTED or SEMI-TRUSTED input reaches logic, storage, or rendering without a filter — the AI flags it. It does not silently pass.

Hard Rules (Never Violated)

• No raw external data in business logic. Ever.
• No silent fallbacks on bad input. Reject explicitly.
• No assuming shape. Even if the API "always" returns a string — validate it.
• No skipping env var checks. Missing env vars must fail loudly at startup, not silently at runtime.
• No partial filtering. If you validate presence but not format, it is not filtered.
• No filtering in the wrong place. Filters go at the entry point — not somewhere downstream after the data has already been used once.

What This Skill Prevents

• SQL injection via unvalidated query params
• Crashes from unexpected API response shapes
• XSS from unescaped user content rendered to UI
• Silent failures from missing env variables discovered at runtime
• Type errors from assuming external data matches expected shape
• Security vulnerabilities from untrusted data reaching sensitive operations

Quick Reference

| Phase | Action | Writes Code? | |---|---|---| | 1 — Detect | List all entry points in scope | ❌ No | | 2 — Classify | Assign trust level to each input | ❌ No | | 3 — Filter | Write filter layer for all UNTRUSTED + SEMI-TRUSTED | ✅ Yes | | 4 — Verify | Trace each input, confirm filter exists | ❌ No |

Limitations

• Does not apply to purely internal logic with no external data involvement.
• May add verbosity to trivial scripts where strict validation is not required.