[{"slug":"playbook","url":"https://www.syntaqx.com/docs/playbook","title":"The Playbook","description":"How to read the playbook, the principles behind every standard in it, and a map of the whole book, from HTTP fundamentals to leading the team.","section":"start-here","category":"Start Here","tags":["architecture","standards","principles"],"position":1},{"slug":"fundamentals/rest-http-verbs","url":"https://www.syntaqx.com/docs/fundamentals/rest-http-verbs","title":"REST & HTTP Verbs","description":"What GET, QUERY, POST, PUT, PATCH and DELETE promise to clients, caches and retries, and why breaking those promises causes real outages.","section":"fundamentals","category":"Fundamentals","tags":["api","rest","http"],"position":2},{"slug":"fundamentals/time","url":"https://www.syntaqx.com/docs/fundamentals/time","title":"Time & Date Formats","description":"RFC 3339 instants in UTC, local wall-clock times with IANA zones for future events, ISO 8601 durations, and iCalendar rules for anything recurring.","section":"fundamentals","category":"Fundamentals","tags":["time","rfc3339","iso8601","standards"],"position":3},{"slug":"fundamentals/identifier-conventions","url":"https://www.syntaqx.com/docs/fundamentals/identifier-conventions","title":"Identifier Conventions","description":"UUID v7 as the default key, when integers, v4, v5 or ULIDs are the better choice, and what each format reveals, costs, and breaks when you get it wrong.","section":"fundamentals","category":"Fundamentals","tags":["ids","uuid","ulid","database"],"position":4},{"slug":"fundamentals/addresses","url":"https://www.syntaqx.com/docs/fundamentals/addresses","title":"Addresses & Geocoding","description":"Capturing, standardizing, validating and geocoding addresses, what vendor licenses let you store, and keeping postal city, service point and jurisdiction apart.","section":"fundamentals","category":"Fundamentals","tags":["addresses","geocoding","data-modeling","standards","time-zones"],"position":5},{"slug":"fundamentals/phones-and-emails","url":"https://www.syntaqx.com/docs/fundamentals/phones-and-emails","title":"Phone Numbers & Email Addresses","description":"Phone numbers in E.164 via libphonenumber, email accepted broadly and compared with care, ownership proven, and what was typed kept beside every key.","section":"fundamentals","category":"Fundamentals","tags":["phone-numbers","email","e164","data-modeling","standards","privacy"],"position":6},{"slug":"fundamentals/text-and-unicode","url":"https://www.syntaqx.com/docs/fundamentals/text-and-unicode","title":"Text & Unicode","description":"UTF-8 everywhere, four ways to measure a string, NFC for storage, case folding, locale-aware collation, confusables, bidi controls and database encodings.","section":"fundamentals","category":"Fundamentals","tags":["unicode","utf-8","text","standards","databases","security"],"position":7},{"slug":"product/discovery","url":"https://www.syntaqx.com/docs/product/discovery","title":"Discovery & User Research","description":"Finding problems worth solving before a problem statement: weekly customer contact, interviews about past behavior, assumption tests and small usability tests.","section":"product","category":"Product","tags":["product","discovery","user-research","usability"],"position":8},{"slug":"product/problem-statements","url":"https://www.syntaqx.com/docs/product/problem-statements","title":"Problem Statements & Acceptance Criteria","description":"Problem statements that set the frame, acceptance criteria that state outcomes and leave room for the solution, and hearing the pain behind a request.","section":"product","category":"Product","tags":["product","requirements","acceptance-criteria","planning"],"position":9},{"slug":"product/backlogs","url":"https://www.syntaqx.com/docs/product/backlogs","title":"Backlogs","description":"One backlog for features, bugs and tech debt, sized to what the team can build, with stale items closed on a schedule and important ideas left to come back.","section":"product","category":"Product","tags":["product","backlog","planning","prioritization"],"position":10},{"slug":"product/roadmaps","url":"https://www.syntaqx.com/docs/product/roadmaps","title":"Roadmaps & Capacity","description":"Roadmaps that commit to problems and outcomes, not dated feature lists, with a fixed share of capacity engineering spends on debt, upgrades and improvements.","section":"product","category":"Product","tags":["product","roadmap","planning","tech-debt"],"position":11},{"slug":"product/release-stages","url":"https://www.syntaqx.com/docs/product/release-stages","title":"Release Stages","description":"Internal, alpha, beta and general availability as gates: who gets access at each stage, what each one promises, and what must be true before the next.","section":"product","category":"Product","tags":["product","releases","beta","launch"],"position":12},{"slug":"development/design-docs","url":"https://www.syntaqx.com/docs/development/design-docs","title":"Decisions & Design Docs","description":"How much process a decision deserves, a named decider and a date, disagree and commit, and design docs and ADRs that keep the reasoning findable later.","section":"development","category":"Development","tags":["process","architecture","adr","documentation","decisions","leadership"],"position":13},{"slug":"development/repositories","url":"https://www.syntaqx.com/docs/development/repositories","title":"Repositories & Local Development","description":"One repository per product, trunk-based development with short branches, one command from clone to running, and formatters and linters CI enforces.","section":"development","category":"Development","tags":["process","git","monorepo","local-development","tooling"],"position":14},{"slug":"development/commits-and-reviews","url":"https://www.syntaqx.com/docs/development/commits-and-reviews","title":"Commits, PRs & Code Review","description":"Conventional Commits, small squash-merged pull requests with a real description, and code reviews that are fast, labeled, and focused on what matters.","section":"development","category":"Development","tags":["process","git","code-review","commits"],"position":15},{"slug":"development/code-ownership","url":"https://www.syntaqx.com/docs/development/code-ownership","title":"Code Ownership","description":"Every service and directory has an owning team: CODEOWNERS for reviews, a catalog entry for operations, and a README that gets anyone running in one command.","section":"development","category":"Development","tags":["ownership","process","documentation","codeowners"],"position":16},{"slug":"development/documentation","url":"https://www.syntaqx.com/docs/development/documentation","title":"Documentation","description":"Docs as code in the repository, reviewed and checked in CI, sorted by Diátaxis, API reference generated from OpenAPI, and every page owned and kept fresh.","section":"development","category":"Development","tags":["documentation","process","openapi","diataxis","agents"],"position":17},{"slug":"development/dependencies","url":"https://www.syntaqx.com/docs/development/dependencies","title":"Dependencies & Upgrades","description":"Lockfiles, SemVer, small continuous upgrades, an LTS runtime policy, vetting new dependencies, and supply-chain safeguards like provenance and pinned CI.","section":"development","category":"Development","tags":["dependencies","security","supply-chain","process","upgrades","maintenance"],"position":18},{"slug":"development/build-vs-buy","url":"https://www.syntaqx.com/docs/development/build-vs-buy","title":"Build vs Buy & Vendors","description":"Buy what isn't your differentiator, total cost both ways, vendor evaluation and security review, exit plans, third-party risk, sprawl, open source and renewals.","section":"development","category":"Development","tags":["build-vs-buy","vendors","procurement","third-party-risk","architecture","cost"],"position":19},{"slug":"development/tech-debt","url":"https://www.syntaqx.com/docs/development/tech-debt","title":"Tech Debt","description":"Treat tech debt like a loan: know which kind you took on, track the interest you pay, budget a steady share to repay it, and modernize with strangler figs.","section":"development","category":"Development","tags":["tech-debt","process","architecture","planning"],"position":20},{"slug":"development/ai-assisted-development","url":"https://www.syntaqx.com/docs/development/ai-assisted-development","title":"AI-Assisted Development","description":"Working with AI coding agents: a person owns every change, review follows measured risk, standards live in the repo, CI enforces them, nothing ships unverified.","section":"development","category":"Development","tags":["ai","agents","process","security"],"position":21},{"slug":"architecture/service-boundaries","url":"https://www.syntaqx.com/docs/architecture/service-boundaries","title":"Service Boundaries","description":"Where to draw lines in a system: start with a modular monolith, split only for a reason, give every piece of data one owner, and never share a database.","section":"architecture","category":"Architecture","tags":["architecture","microservices","monolith","design"],"position":22},{"slug":"architecture/retries-and-timeouts","url":"https://www.syntaqx.com/docs/architecture/retries-and-timeouts","title":"Retries & Timeouts","description":"When to retry, how long to wait, and when to give up: timeouts on every call, exponential backoff with jitter, retry budgets, and what is safe to retry.","section":"architecture","category":"Architecture","tags":["reliability","retries","timeouts","operations"],"position":23},{"slug":"architecture/events","url":"https://www.syntaqx.com/docs/architecture/events","title":"Events & Async Messaging","description":"Publishing and consuming events reliably: the transactional outbox, idempotent consumers, partition keys for ordering, CloudEvents, and schema evolution.","section":"architecture","category":"Architecture","tags":["architecture","events","messaging","cloudevents"],"position":24},{"slug":"architecture/background-jobs","url":"https://www.syntaqx.com/docs/architecture/background-jobs","title":"Background Jobs","description":"Moving work out of the request: small idempotent jobs, retries with backoff and dead letters, scheduling without overlap, visibility, and shutting down cleanly.","section":"architecture","category":"Architecture","tags":["architecture","jobs","queues","reliability"],"position":25}]