Primary-source map

Status: Complete. Last reviewed 2026-08-28.

Use this map to verify version-sensitive claims and locate the authority behind a topic. It favors specifications, official project documentation and source, standards bodies, and recognized foundational publications. Topic pages carry narrower citations; this page intentionally remains selective rather than duplicating every source list.

For concise local navigation, use the terminology glossary and common-confusions index; both link back to owning explanations and relevant authorities here.

PHP

• Language and runtime: PHP manual, language reference, migration appendices, and supported versions.
• Language evolution and implementation: PHP RFC index and the php-src repository. An accepted RFC explains intent; the manual and implementation establish shipped behavior for a particular release.
• Packages and interoperability: Composer documentation, Composer schema, and the PHP-FIG PSR index.

Laravel

• Release and compatibility: Laravel release notes and support policy, upgrade guides, and the repository’s version guide.
• Framework mechanisms: the official documentation entry points for the request lifecycle, service container, database, queues, testing, and deployment.
• Implementation details: laravel/framework source and the Laravel API reference. Select the branch or API version matching the application before drawing conclusions from internals.

Wave 3 authorities: backend engineering core

• Protocols and API contracts: RFC 9110: HTTP semantics, RFC 9111: HTTP caching, and the OpenAPI specification.
• Data and caching guarantees: PostgreSQL documentation, MySQL 8.4 reference manual, and Redis documentation. Verify isolation, locking, DDL, plans, persistence, and replication against the deployed product and version.
• Concurrency and delivery: PHP fibers, Reactive Streams, Apache Kafka design, RabbitMQ confirms and acknowledgements, and the CloudEvents specification.
• Quality and security: PHPUnit documentation, PHPStan user guide, OWASP Application Security Verification Standard, and NIST Secure Software Development Framework.
• Capacity and reliability: the Google SRE chapters on handling overload and addressing cascading failures, plus OpenTelemetry signals.

Wave 4 authorities: senior engineering and leadership

• Software design and architecture: Parnas’s module-decomposition paper, Liskov and Wing’s behavioral subtyping paper, Evans’s Domain-Driven Design Reference, and Cockburn’s Hexagonal Architecture.
• Release engineering and recovery: the Google SRE chapter on release engineering, the OCI image specification, the SLSA specification, Kubernetes Deployments, and NIST contingency-planning guidance.
• Observability and incidents: OpenTelemetry specifications, W3C Trace Context, the Google SRE Workbook guidance on implementing SLOs, and NIST incident-response recommendations.
• Technical leadership: Google Engineering Practices on the code-review standard, the U.S. GAO cost-estimating guide, and AWS Prescriptive Guidance on architecture decision records.
• System design: use the governing sources for each decision, especially RFC 9110, the OpenAPI specification, PostgreSQL transaction isolation, the OWASP ASVS, and the Google SRE guidance on overload.

Wave 5 authorities: browser, frontend, and accessibility

• Web platform behavior: the WHATWG HTML Living Standard, including event loops and Web Storage, the WHATWG Fetch Standard, and ECMAScript. These define browser mechanisms; compatibility still depends on deployed browser support.
• Cookies and browser security: RFC 6265, the WHATWG Storage Standard, and OWASP guidance for cross-site scripting prevention and CSRF prevention.
• Accessibility: W3C Web Content Accessibility Guidelines 2.2, WAI-ARIA 1.2, and the WAI ARIA Authoring Practices Guide. Native HTML semantics remain the first choice; ARIA defines accessibility semantics, not visual or application behavior.
• Laravel frontend approaches: official documentation for Blade, Livewire, Inertia, and Vite, read alongside the local approach comparison.

Wave 5 authorities: AI, MCP, and evaluation

• Model foundations and changing APIs: Vaswani et al., Attention Is All You Need, plus current vendor documentation for the exact model and controls in use, such as OpenAI’s model and function-calling guides. A research architecture or vendor API page does not establish the behavior of every deployed model.
• MCP: the Model Context Protocol specification and official security best practices, read alongside the local tool-boundary example and terminology distinction.
• Evaluation and risk: NIST’s AI Risk Management Framework, OpenAI’s evaluation best practices, and the OWASP Top 10 for LLM Applications. Use representative local cases and explicit acceptance thresholds rather than treating a vendor benchmark or one successful prompt as deployment evidence.