Mission & Audience

• Build Tales is a technical blog focused on systems thinking, U.S. payments, compliance, and engineering leadership.
• Target readers: senior engineers, staff+ ICs, first-time tech leads, and fintech operators who want implementation-ready guidance.
• Every deliverable should feel like a field guide: pragmatic, specific, and grounded in production reality.

Core Content Pillars

1. U.S. Payments Series – ACH, wires, FedNow/RTP, crypto rails, NACHA rules, fraud, reconciliation, and regulatory risk.
2. Engineering Leadership – team building, incident management, compliance-minded execution, and scaling engineering practices.
3. Systems & Architecture – resilience engineering, scalability patterns, third-party integrations, and observability-first design.
4. Fintech Deep Dives – banking infrastructure, compliance engineering, risk engines, and monitoring playbooks.

Brand Voice

• Professional yet approachable; mix narrative storytelling with detailed runbooks.
• Start from real-world constraints (compliance limits, throughput, SLAs) before showing solutions.
• Treat resilience, metrics, and observability as non-negotiable; “ship + monitor” beats “ship + hope”.
• Use confident, directive language (“Instrument every ACH corridor with …”) rather than hedging.

Do / Don’t

• Do cite realistic-but-fictitious companies, routing numbers, dates, and IDs so examples feel production-ready.
• Do convert all money movement into cents when showing backend payloads; surface formatted dollars only in UI layers.
• Do tie claims back to metrics (latency, MTTR, R01 rate) or referenced regulations.
• Don’t use anonymous placeholders like “Customer A” or “Bank 1”; instead, invent plausible institutions with constraints.
• Don’t mention unverified vendor claims or quote marketing copy—ground recommendations in observed data or regulations.
• Don’t write motivational fluff; every paragraph must teach a mechanism, control, or measurable outcome.

Quality Bar

• Provide runnable code, diagrams, and validation steps; nothing is purely theoretical.
• Include regulatory context (Reg E, UDAAP, NACHA, FFIEC) whenever discussing payments.
• Prefer descriptive nouns over jargon (e.g., “Originating Depository Financial Institution (ODFI)” instead of just “ODFI” on first mention).
• Always reference real identifiers where helpful (routing 061000052, trace IDs, production-like dataset names).

Canonical Sources & Processes

• System of record for rules: .cursorrules (legacy) + cursor/rules pack (modular).
• Build command: bundle exec jekyll build → deploy _site/ to Netlify.
• All secrets flow through Netlify env vars; never bake them into docs or code samples.

Use this file together with the scoped rule files below so Cursor maintains consistent guidance regardless of which folders you reference.