SEO / Portfolio / Public Site

Technical Architecture and Implementation Strategy for IntelligenceCompact.com

Report summary

The digital infrastructure for IntelligenceCompact.com is engineered to fulfill a rigorous set of constraints: absolute data sovereignty, zero third-party runtime dependencies, maximum durability, exceptional performance, and native optimization for both traditional Search Engine Optimization (SEO)

Status
Research archive item
Category
SEO / Portfolio / Public Site
Length
4,506 words
Reading time
21 minutes
Report type
strategy

Key topics

  • SEO / Portfolio / Public Site
  • SEO
  • Portfolio
  • Public Site
  • AI
  • Agentic Web
  • AEO
  • GEO
  • .NET

Research provenance

Archive status
Research archive item
Content identity
sha256:2ba4f93633ffd7e407e36ebef155251d5b44ca8ffc71300cd9370810fd632a4f

For citation, use the report title and canonical URL. Archival presence does not establish authorship or promote report statements into portfolio evidence.

This page renders the archived Markdown as safe, formatted HTML. It is background research and does not become a portfolio claim without evidence review.

Full report

On this page

Executive Summary and Architectural Philosophy

The digital infrastructure for IntelligenceCompact.com is engineered to fulfill a rigorous set of constraints: absolute data sovereignty, zero third-party runtime dependencies, maximum durability, exceptional performance, and native optimization for both traditional Search Engine Optimization (SEO) and emerging Generative Engine Optimization (GEO). The foundational philosophy dictating this architecture is Progressive Enhancement combined with Machine Readability. The platform guarantees that all content, structure, and metadata are delivered via pristine, semantic HTML and structured JSON-LD. JavaScript is strictly optional, utilized exclusively to enhance user experience rather than serving as a prerequisite for content delivery or rendering. By eliminating reliance on external Content Delivery Networks (CDNs), Software-as-a-Service (SaaS) providers, hosted analytics, external typography, and external search services, the architecture removes third-party points of failure, mitigates user tracking risks, and achieves near-instantaneous page load speeds. The resulting system is a fast, durable, auditable, and privacy-respecting research publication entirely under the operator's control.

1. Core Technology Stack and Runtime Environment

The technology stack relies exclusively on robust, natively compiled server software and standard web languages, ensuring zero external runtime dependencies.

LayerTechnologyJustification and Role
Operating SystemLinux (Debian/Ubuntu LTS)Provides a stable, auditable, and widely supported base environment.
Web ServerNginxHandles static file delivery, compression (Brotli/Gzip), TLS termination, and reverse-proxying to PHP-FPM.
Application LogicPHP 8.4Executes server-side routing, Markdown parsing, and database interaction. Utilizes advanced OPcache and Just-In-Time (JIT) compilation for extreme performance1.
DatabaseSQLite 3Zero-configuration, serverless, file-backed database3. Facilitates complex relational querying and internal full-text search without the overhead of a daemonized database process.
Content FormatMarkdown (CommonMark/GFM)A highly durable, machine-readable flat-file format for authoring research. Parsed via zero-dependency pure-PHP parsers4.
Search EngineSQLite FTS5Native Virtual Table extension enabling high-performance, BM25-ranked full-text search directly within the SQLite file3.
AuthenticationPure PHP TOTP (RFC 6238\)Time-based one-time passwords for administrative access, functioning entirely on-server without external authentication providers6.

2. Content Storage Paradigm: The Hybrid Architecture

A critical architectural decision involves determining the primary storage medium for the research publication. Evaluating the options reveals specific trade-offs:

  • Pure Markdown / Flat Files: Excellent for durability, version control (Git), and machine readability, but highly inefficient for relational queries (e.g., filtering articles by author, date, and tag simultaneously) and completely lacks native search capabilities.
  • MySQL/MariaDB: Excellent for relational data and concurrency, but introduces a heavy external daemon dependency, increases server resource requirements, and complicates the backup and migration processes.
  • Pure SQLite: Excellent for read-heavy workloads, portable (single file), and supports full-text search. However, writing long-form research directly into a database abstracts the content away from highly durable, human-readable flat files.

The optimal solution is a Hybrid Architecture that leverages the strengths of both Markdown and SQLite. Content is authored and durably stored as Markdown (.md) files containing YAML frontmatter (metadata). These files are committed to a Git repository, providing an immutable, cryptographically verifiable revision history. Upon deployment or article publication, a PHP synchronization script parses the Markdown frontmatter and ingests the structured data and rendered HTML into an SQLite database. This hybrid model guarantees that the source of truth remains in auditable, plain-text files, while the application layer benefits from high-speed relational queries, pagination, and advanced full-text search via SQLite's FTS5 extension8.

2.1 Database Schema and Configuration

The SQLite database must be configured to maximize concurrent read performance while maintaining durability. Setting the journal mode to Write-Ahead Logging (WAL) allows readers to access the database simultaneously while a write operation occurs. When WAL mode is active, setting the synchronous pragma to NORMAL provides a safe balance between data integrity and write speed10.

SQL PRAGMA journal\_mode \= WAL; PRAGMA synchronous \= NORMAL; PRAGMA foreign\_keys \= ON;

CREATE TABLE authors ( id TEXT PRIMARY KEY, name TEXT NOT NULL, bio TEXT, schema\_url TEXT );

CREATE TABLE articles ( id TEXT PRIMARY KEY, slug TEXT UNIQUE NOT NULL, title TEXT NOT NULL, abstract TEXT, author\_id TEXT REFERENCES authors(id), published\_at DATETIME, updated\_at DATETIME, confidence\_level TEXT, markdown\_path TEXT NOT NULL, html\_cache TEXT );

CREATE TABLE citations ( id TEXT PRIMARY KEY, article\_id TEXT REFERENCES articles(id), primary\_source\_url TEXT, citation\_text TEXT );

2.2 Markdown Parsing Strategy

To parse the Markdown files into HTML without relying on massive, regex-heavy libraries or external dependencies, the architecture utilizes a pure-PHP solution. Traditional parsers often rely heavily on complex regular expressions, which can degrade performance on large documents. Modern PHP implementations, such as the tempest/markdown package or the highly optimized parsedown single-file library, utilize abstract syntax tree (AST) tokenization or highly optimized single-pass lexing to achieve spec compliance and extreme speed4. These parsers ensure that the conversion from Markdown to semantic HTML occurs in milliseconds, well within the performance budget.

3. Directory Structure and Request Lifecycle

The application directory structure enforces a strict security boundary by isolating the document root from application logic, configuration data, and the raw database file.

3.1 Directory Layout

/var/www/intelligencecompact/ ├── backups/ \# Automated SQLite and Markdown archives ├── core/ \# PHP application logic (not web-accessible) │ ├── Auth/ \# TOTP and Session management │ ├── Controllers/ \# Route handlers and pagination logic │ ├── Database/ \# SQLite connection and query builders │ ├── Parsers/ \# Zero-dependency Markdown parsers │ └── Views/ \# Semantic HTML templates ├── content/ \# Source of truth for content │ ├── articles/ \# .md files organized by year/month │ ├── authors/ \# .md files for author bios │ └── dictionary/ \# .md files for defined terms ├── data/ \# Database storage (not web-accessible) │ └── compact.sqlite \# SQLite database file ├── logs/ \# Nginx access/error logs and PHP logs ├── public/ \# Document Root (Web-accessible) │ ├── index.php \# Front Controller │ ├── assets/ \# Self-hosted CSS, JS, and optimized Images │ ├── fonts/ \# Self-hosted WOFF2 fonts (if system fonts are unused) │ ├── cache/ \# Statically generated HTML files │ ├── favicon.ico \# Legacy 32x32 favicon │ ├── icon.svg \# Modern scalable vector favicon │ ├── manifest.webmanifest \# Web manifest │ ├── robots.txt \# Crawler directives │ ├── sitemap\_index.xml \# Sitemap index │ └── llms.txt \# AI Discovery index └── scripts/ \# CLI deployment and synchronization tools

3.2 Request Lifecycle and PHP Routing

To eliminate the overhead of external web frameworks (e.g., Laravel, Symfony), the architecture implements a lightweight, native PHP front controller.

1. Web Server Interception: Nginx receives the HTTP request. It first checks if a statically generated .html file exists in /public/cache/ matching the request URI. If it exists, and the user does not possess an active administrative session cookie, Nginx serves the file directly, bypassing PHP entirely and achieving a Time to First Byte (TTFB) of under 20 milliseconds.

2. Front Controller (index.php): If the static cache is missed, Nginx routes the request to index.php.

3. Security and Environment Initialization: PHP initializes strict session parameters, applies HTTP security headers, and bootstraps the SQLite connection.

4. Regex Routing Engine: A lightweight router evaluates $\_SERVER\['REQUEST\_URI'\]. It strips query parameters (used for search and pagination) and matches the path against defined patterns (e.g., /research/(\[a-z0-9-\]+)).

5. Controller Invocation: The appropriate controller fetches data from SQLite. For paginated archive pages, it calculates offsets using the ?page= parameter and applies LIMIT and OFFSET to the SQL query.

6. Redirection Handling: If a slug has changed, the router checks a redirects table in SQLite and issues an immediate HTTP 301 Moved Permanently response.

7. View Rendering: Data is injected into semantic HTML templates.

8. Output and Cache Generation: The output is flushed to the client. Simultaneously, if the request is cacheable, the HTML is written to the /public/cache/ directory for subsequent requests.

4. Performance Engineering and Caching Strategy

Performance optimization ensures the platform meets the criteria for excellent Core Web Vitals, specifically targeting a Largest Contentful Paint (LCP) of under 1.5 seconds and a Cumulative Layout Shift (CLS) of zero.

4.1 PHP 8.4 OPcache and JIT Configuration

PHP 8.4 introduces highly optimized Just-In-Time (JIT) compilation, which significantly accelerates CPU-bound tasks such as Markdown tokenization and HTML rendering. By default, JIT is disabled in PHP 8.4; it must be explicitly enabled via the INI configuration1. Furthermore, OPcache preloading is utilized to compile core application classes into shared memory at server startup, eliminating file I/O overhead during request execution13.

Ini, TOML ; php.ini configuration opcache.enable \= 1 opcache.memory\_consumption \= 256 opcache.max\_accelerated\_files \= 10000 opcache.validate\_timestamps \= 0 ; Files are validated manually during deployment opcache.preload \= /var/www/intelligencecompact/core/preload.php opcache.preload\_user \= www-data

; Enable JIT compilation for CPU-heavy tasks opcache.jit \= tracing opcache.jit\_buffer\_size \= 128M

4.2 Compression and Asset Optimization

All textual responses (HTML, CSS, JSON, XML) are compressed using the Brotli algorithm (configured at level 5 in Nginx) to achieve maximum compression ratios without excessive CPU overhead, falling back to Gzip for older clients. Visual assets are rigorously optimized:

  • Responsive Images: All images are locally hosted, converted to modern formats (AVIF with WebP fallbacks), and served via \<picture\> elements. They include explicit width and height attributes, alongside loading="lazy" and decoding="async", entirely eliminating layout shifts (CLS).
  • Typography: The platform defaults to a local system font stack (font-family: system-ui, \-apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, sans-serif;). This guarantees zero external requests, zero layout shift (no Flash of Unstyled Text), and instant text rendering.

5. Security and Privacy Infrastructure

Adhering to strict security priorities, the architecture defends against Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), and unauthorized access using exclusively first-party mechanisms.

5.1 HTTP Security Headers

Nginx is configured to inject mandatory security headers into every response:

  • Content-Security-Policy: default-src 'self'; img-src 'self' data:; font-src 'self'; frame-ancestors 'none'; base-uri 'self'; form-action 'self';
  • Justification: This strict CSP ensures that no inline scripts can execute (unsafe-inline is omitted) and prevents the browser from loading assets, scripts, or frames from any external domain, neutralizing XSS vectors.
  • Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
  • Justification: HSTS forces all connections over TLS for two years, preventing protocol downgrade attacks.
  • X-Content-Type-Options: nosniff
  • Justification: Prevents MIME-type sniffing.
  • X-Frame-Options: DENY
  • Justification: Mitigates clickjacking attacks.

5.2 PHP Session Hardening

PHP session configuration is hardened to prevent session hijacking and fixation. The session.cookie\_samesite directive is set to Strict to prevent the browser from sending the session cookie along with cross-site requests, mitigating CSRF vulnerabilities15.

Ini, TOML session.cookie\_secure \= 1 session.cookie\_httponly \= 1 session.cookie\_samesite \= "Strict" session.use\_strict\_mode \= 1 session.use\_only\_cookies \= 1 expose\_php \= Off

5.3 Administrative Authentication (Zero-Dependency TOTP)

To fulfill the mandate forbidding external SaaS (such as Okta or Auth0), administrative authentication relies on a custom, highly secure implementation. Access requires a username, a high-entropy passphrase hashed via password\_hash() using the ARGON2ID algorithm, and a Time-Based One-Time Password (TOTP). A pure-PHP implementation of RFC 6238 is utilized to validate the 6-digit codes generated by the administrator's local authenticator application6. To mitigate timing attacks, validation relies exclusively on the hash\_equals() function for constant-time string comparison, and previously used codes are blacklisted for the duration of their validity window17.

5.4 Privacy-Preserving Server Logs

Third-party hosted analytics services (e.g., Google Analytics) inherently violate user privacy and platform sovereignty constraints. Instead, intelligence gathering relies strictly on Nginx server access logs. The logs are configured to anonymize visitor IP addresses by masking the final octet. A local, scheduled script (such as GoAccess) parses these logs nightly to generate a static HTML dashboard detailing page views, referrers, and AI crawler activity, ensuring compliance with global privacy regulations while maintaining zero external footprint.

6. Generative Engine Optimization (GEO) and AI Discoverability

Generative Engine Optimization represents a paradigm shift from keyword density to entity disambiguation, machine readability, and citation surfacing. The architecture treats AI crawlers as primary stakeholders.

6.1 Adoption and Implementation of llms.txt

The /llms.txt specification is an emerging standard designed to provide Large Language Models (LLMs) and agentic browsers with a curated, Markdown-based map of a website's most critical information. Recent data indicates that adoption is growing rapidly among technical sites; studies from June 2026 show that approximately 8.7% of the top 1,000 websites publish an llms.txt file, with some indices placing upper-bound adoption as high as 28% among SEO-aware domains18. While major search engines have explicitly stated that llms.txt is not currently used as a primary ranking signal for traditional search, it is actively consumed by Model Context Protocol (MCP) integrations, Retrieval-Augmented Generation (RAG) pipelines, and AI-assisted Integrated Development Environments (IDEs)20. Google's own Chrome Developer tools now feature Lighthouse audits for llms.txt under "Agentic browsing," indicating its future utility22. The platform will publish two files at the domain root:

1. /llms.txt: A concise index containing the site's purpose and Markdown links to the most critical research articles.

2. /llms-full.txt: A concatenated Markdown file containing the full text of primary research, facilitating immediate context-window ingestion for research agents.

Structure of llms.txt:

IntelligenceCompact.com

IntelligenceCompact provides deeply researched, zero-dependency architectural and strategic intelligence.

Research Articles

6.2 AI Crawler Controls via robots.txt

To ensure that research is ingested and cited by major generative AI platforms (such as ChatGPT, Claude, and Perplexity), the robots.txt file explicitly permits known AI user agents, distinguishing between training crawlers and user-triggered search agents23. User-agent: \* Allow: /

Explicitly permit AI crawlers for GEO discoverability

User-agent: GPTBot Allow: / User-agent: ChatGPT-User Allow: / User-agent: ClaudeBot Allow: / User-agent: Claude-User Allow: / User-agent: PerplexityBot Allow: / User-agent: OAI-SearchBot Allow: / User-agent: Google-Extended Allow: / Sitemap: https://intelligencecompact.com/sitemap\_index.xml

7. Semantic HTML, Metadata, and Schema Structure

For both SEO and AEO, the presentation of content must be unambiguously parsable without JavaScript execution. The platform exposes every requested research metric through a combination of native semantic HTML5 elements and rigorous JSON-LD structured data.

7.1 Exposing Research Page Elements in HTML

The rendering engine maps the required research components to specific semantic tags to maximize machine comprehension:

Required ElementSemantic HTML Implementation
Clear Title\<h1\> element acting as the sole primary heading within the main \<article\>.
Canonical URL\<link rel="canonical" href="..."\> in the document \<head\>.
Author\<address rel="author"\> linking to the dedicated author biography page.
Publication Date\<time itemprop="datePublished" datetime="YYYY-MM-DD"\>
Last-Reviewed Date\<time itemprop="dateModified" datetime="YYYY-MM-DD"\>
Abstract\<section id="abstract" class="lead"\> immediately following the title.
Concise AnswerA specific \<div class="executive-summary"\> formatted for immediate extraction by AI Overviews.
Definitions\<dfn\> tags wrapping defined terminology throughout the text.
Major ClaimsSemantic \<blockquote\> or distinct \<section\> tags outlining core assertions.
Supporting Citations / Primary SourcesSidenotes utilizing \<aside\> and \<cite\> tags, linked via intra-document anchors (\<a href="\#cite-1"\>).
Opposing Arguments\<section id="counter-analysis"\> clearly denoting contrasting viewpoints.
Confidence LevelA visual and semantic \<span class="badge confidence-high"\> indicating the epistemological weight of the research.
Revision HistoryA \<details\> block at the footer enumerating versioning and date-based textual updates.

7.2 First-Party JSON-LD Structured Data

Schema.org JSON-LD is the most efficient mechanism for delivering structured context to Large Language Models and search engines26. The PHP application dynamically generates this JSON block and injects it into the \<head\>, requiring zero client-side processing. The platform utilizes a highly nested array of schemas to cover the entire scope of the research publication, specifically leveraging ScholarlyArticle, Person, Organization, DefinedTerm, and BreadcrumbList. Example: Comprehensive JSON-LD Implementation \[cite: 27, 28, 29\]

JSON { "@context": "https://schema.org", "@graph": \[ { "@type": "Organization", "@id": "https://intelligencecompact.com/\#organization", "name": "IntelligenceCompact", "url": "https://intelligencecompact.com/", "logo": { "@type": "ImageObject", "url": "https://intelligencecompact.com/icon.svg" } }, { "@type": "Person", "@id": "https://intelligencecompact.com/authors/jane-doe/\#person", "name": "Jane Doe", "jobTitle": "Lead Architect", "url": "https://intelligencecompact.com/authors/jane-doe/" }, { "@type": "ScholarlyArticle", "@id": "https://intelligencecompact.com/research/zero-dependency/\#article", "headline": "Zero-Dependency Web Architectures for Sovereign Intelligence", "abstract": "An exhaustive analysis of implementing PHP 8.4 and SQLite to achieve complete data sovereignty.", "url": "https://intelligencecompact.com/research/zero-dependency/", "datePublished": "2026-09-04T12:00:00+00:00", "dateModified": "2026-09-05T08:00:00+00:00", "author": { "@id": "https://intelligencecompact.com/authors/jane-doe/\#person" }, "publisher": { "@id": "https://intelligencecompact.com/\#organization" }, "license": "https://creativecommons.org/licenses/by/4.0/", "reviewAspect": "High Confidence", "citation": \[ { "@type": "CreativeWork", "text": "W3C Web Content Accessibility Guidelines (WCAG) 2.2", "url": "https://www.w3.org/TR/WCAG22/" } \] }, { "@type": "DefinedTerm", "@id": "https://intelligencecompact.com/dictionary/\#zero-dependency", "name": "Zero-Dependency Architecture", "description": "A system design pattern that relies exclusively on first-party hosted code.", "inDefinedTermSet": "https://intelligencecompact.com/dictionary/" }, { "@type": "BreadcrumbList", "itemListElement": \[ { "@type": "ListItem", "position": 1, "name": "Research", "item": "https://intelligencecompact.com/research/" }, { "@type": "ListItem", "position": 2, "name": "Zero-Dependency Architectures", "item": "https://intelligencecompact.com/research/zero-dependency/" } \] } \] }

7.3 Feeds, Sitemaps, and Metadata

  • RSS/Atom Feeds: The platform generates valid XML Atom feeds directly from the SQLite database. These feeds contain full-text HTML content, ensuring readers and aggregators do not need to visit the site to consume the intelligence.
  • Sitemap Architecture: An XML sitemap\_index.xml points to specialized sitemaps (sitemap\_articles.xml, sitemap\_authors.xml, sitemap\_dictionary.xml). The article sitemap dynamically includes the \<lastmod\> tag derived from the updated\_at database column, ensuring rapid re-crawling upon revision.
  • OpenGraph Metadata: Social sharing optimization is handled natively via \<meta property="og:title"\>, \<meta property="og:description"\>, and \<meta property="og:type" content="article"\> tags in the document head.

8. Internal Site Search (Zero External Services)

To fulfill the strict constraint forbidding externally hosted search services (such as Algolia or Elasticsearch), the architecture leverages the highly capable SQLite FTS5 (Full-Text Search) extension3. FTS5 creates a virtual table (articles\_fts) that indexes the title, abstract, and body of the research articles. This table is kept perfectly synchronized with the primary articles table using a series of SQLite AFTER INSERT, AFTER UPDATE, and AFTER DELETE triggers3. When a user initiates a search, the PHP controller executes a query utilizing the BM25 ranking algorithm, which assigns relevance scores based on term frequency and inverse document frequency3.

SQL SELECT a.slug, a.title, snippet(articles\_fts, 2, '\<mark\>', '\</mark\>', '...', 64) AS excerpt, bm25(articles\_fts, 5.0, 2.0, 1.0) AS relevance\_score FROM articles\_fts fts JOIN articles a ON a.rowid \= fts.rowid WHERE articles\_fts MATCH :query ORDER BY relevance\_score ASC LIMIT 20 OFFSET :offset;

This approach provides instantaneous, highly relevant search results without requiring external network requests. Furthermore, the SQLite snippet() function natively generates contextual text excerpts with the search terms automatically wrapped in \<mark\> tags, shifting the highlighting workload to the C-compiled database engine rather than relying on slower PHP string manipulation3.

9. Accessibility Compliance (WCAG 2.2 AA)

Web Content Accessibility Guidelines (WCAG) 2.2 introduces stringent requirements designed to accommodate users with cognitive, low-vision, and motor disabilities33. The platform achieves Level AA compliance through strict adherence to semantic HTML and highly specific CSS styling.

CSS a:focus\-visible, button:focus\-visible { outline: 2px solid \#005fcc; outline-offset: 2px; }

  • Target Size (Minimum) (2.5.8): All interactive elements, including pagination links, internal citations, and navigation buttons, are designed with a minimum target size of 24x24 CSS pixels. This is enforced via CSS padding and minimum dimensions, ensuring usability for individuals with motor impairments34.
  • Focus Appearance (2.4.13): Keyboard navigation focus states are explicitly designed, overriding insufficient browser defaults. The focus indicator guarantees a 3:1 contrast ratio against adjacent colors and utilizes an outline that is at least 2 pixels thick, ensuring clear visibility33.
  • Focus Not Obscured (Minimum) (2.4.11): The design deliberately avoids fixed or "sticky" headers that could obscure focused elements during keyboard scrolling. Where sticky elements are necessary, the CSS scroll-padding-top property is utilized to ensure the browser scrolls focused elements completely into the visible viewport33.
  • Accessible Authentication (3.3.8): The administrative login portal supports password managers by utilizing standard \<input type="password" autocomplete="current-password"\> attributes. It also allows the pasting of TOTP codes, ensuring that users are never forced to pass a "cognitive function test" (such as memorizing a password or transcribing a code) to authenticate34.

10. Favicon and Web Manifest Specification

To eliminate dependencies on third-party generators and bloated asset delivery, first-party iconography is strictly specified to cover all modern contexts with minimal file overhead.

1. /favicon.ico: A 32x32 legacy format retained solely for RSS readers and legacy automated bots.

2. /icon.svg: A modern vector format serving as the primary icon for modern browsers. It scales infinitely while requiring only a few kilobytes of bandwidth.

3. /apple-touch-icon.png: A 180x180 PNG specifically designated for iOS home screen bookmarks.

4. /manifest.webmanifest: A JSON file declaring the application name, theme color, and pointing to a 512x512 PNG icon to enable Android and Progressive Web App (PWA) integration.

11. Deployment, Rollback, and Backups

The deployment and backup pipelines ensure atomicity, data safety, and immediate rollback capabilities without relying on external CI/CD SaaS platforms.

Updates to the application code or the addition of new Markdown research articles trigger an automated, atomic deployment process managed entirely on the server.

1. Code and Markdown content are pushed to a secure, self-hosted Git repository.

2. A Git post-receive hook triggers a deployment bash script.

3. The script clones the repository into a new, timestamped directory (e.g., /var/www/releases/20260904\_120000/).

4. The script executes the PHP build step, parsing new Markdown files, syncing them to the SQLite database, and pre-generating static HTML caches.

5. Once the build is verified, the public symlink is updated atomically: ln \-sfn /var/www/releases/20260904\_120000/public /var/www/intelligencecompact/public.

6. The PHP OPcache is flushed to load the new code.

7. Rollback: In the event of a critical failure, the administrator can instantaneously revert the site by pointing the symlink back to the previous release folder.

11.2 Comprehensive Backup Strategy

  • Database: A nightly cron job utilizes SQLite's Online Backup API (sqlite3 data/compact.sqlite ".backup 'backups/compact\_backup.sqlite'") to create a transactionally consistent copy of the database without locking the production file during write operations.
  • Content: Because all articles originate as Markdown tracked in Git, the Git repository itself serves as a highly durable, distributed backup of the intellectual property.
  • Off-site Synchronization: The generated SQLite backups and anonymized server logs are encrypted using GPG and synchronized to a secure, off-site block storage volume nightly via rsync.

12. Deliverables Summary and Implementation Order

The following section explicitly addresses the 21 requested deliverables, consolidating the architectural decisions into a comprehensive summary.

DeliverableResolution / Location
1\. Tech StackLinux, Nginx, PHP 8.4, SQLite 3, Markdown (Zero external dependencies).
2\. Directory StructureDetailed in Section 3.1. Isolates public assets from core application logic and data.
3\. Request LifecycleDetailed in Section 3.2. Nginx static cache \-\> PHP Front Controller \-\> SQLite \-\> View rendering.
4\. Content ModelHybrid Model: Authored in Markdown, synced to SQLite for querying and search.
5\. Database SchemaDetailed in Section 2.1. Includes authors, articles, and citations tables.
6\. Research SchemaDetailed in Section 7.1 and 7.2. Utilizes ScholarlyArticle and Claim JSON-LD.
7\. Routing ArchitectureRegex-based PHP front controller mapping clean URLs to specific SQLite queries.
8\. Caching StrategyNginx serves pre-rendered HTML. PHP OPcache preloads classes. Static assets served with immutable cache headers.
9\. Security ChecklistCSP (no unsafe-inline), HSTS, CSRF tokens, strict session cookies, TOTP admin auth.
10\. SEO ChecklistSemantic HTML, automatic XML sitemaps, canonical tags, zero CLS, sub-100ms TTFB.
11\. AEO ChecklistJSON-LD injection, semantic \<blockquote\> for claims, \<dfn\> for terms, concise answers mapped to specific HTML classes.
12\. GEO ChecklistImplementation of llms.txt, permissive robots.txt for AI agents, machine-readable .md endpoints.
13\. Structured DataExample JSON-LD provided in Section 7.2 covering ScholarlyArticle and DefinedTerm.
14\. Sitemap Architecturesitemap\_index.xml pointing to categorized sitemaps containing \<lastmod\> dates.
15\. Favicon Specfavicon.ico, icon.svg, apple-touch-icon.png, and manifest.webmanifest.
16\. Deployment WorkflowAtomic symlink deployments via Git post-receive hooks.
17\. Backup StrategySQLite Online Backup API, Git repository cloning, and off-site encrypted rsync.
18\. AccessibilityWCAG 2.2 AA compliant focus appearance (2.4.13), target size (2.5.8), and accessible authentication (3.3.8).
19\. Performance BudgetTTFB \< 100ms, LCP \< 1.5s, CLS \= 0\. Achieved via JIT, static caching, and system fonts.
20\. External DependenciesZero. No external CDNs, JS frameworks, hosted fonts, analytics, or search services.

1. Phase 1: Infrastructure and Foundation

  • Provision the Linux server and configure Nginx for static file serving, Brotli compression, and the injection of strict HTTP security headers (CSP, HSTS).
  • Install and harden PHP 8.4; configure OPcache, enable JIT compilation, and secure session directives.
  • Establish the directory structure and the atomic Symlink deployment workflow.

2. Phase 2: Data Architecture and Parsing

  • Initialize the SQLite database, apply the schemas, and configure WAL journaling mode.
  • Integrate a pure-PHP zero-dependency Markdown parser.
  • Write the PHP synchronization scripts responsible for converting Markdown frontmatter into SQLite relational data upon deployment.

3. Phase 3: Routing, Front-End, and Search

  • Implement the native PHP front controller, routing logic, and pagination algorithms.
  • Develop semantic HTML templates adhering strictly to WCAG 2.2 AA focus visibility and target size guidelines.
  • Configure the SQLite FTS5 virtual table, sync triggers, and construct the internal search query utilizing the BM25 algorithm and native snippet highlighting.

4. Phase 4: Optimization, GEO, and Launch

  • Develop the dynamic JSON-LD generators for ScholarlyArticle, DefinedTerm, and BreadcrumbList.
  • Implement /llms.txt and /llms-full.txt generation processes.
  • Configure robots.txt to permit AI agent ingestion.
  • Establish the static HTML caching mechanisms.
  • Deploy the server-log analytics parser (GoAccess).
  • Execute a final quality assurance sweep, security audit, and proceed to production launch.

Works cited

1. PHP 8.4: Opcache: INI changes on how JIT is enabled, https://php.watch/versions/8.4/opcache-jit-ini-default-changes

2. Runtime Configuration \- Manual \- PHP, https://www.php.net/manual/en/opcache.configuration.php

3. Runnable SQLite Docs: Full-Text Search \- Coddy Tech, https://coddy.tech/docs/sqlite/full-text-search

4. Fast and extensible Markdown in PHP · GitHub, https://github.com/tempestphp/markdown

5. Better Markdown Parser in PHP, https://parsedown.org/

6. GitHub \- remotemerge/totp-php: Lightweight, fast, and secure TOTP, https://github.com/remotemerge/totp-php

7. TOTP Authenticator: A Lightweight PHP Library for Secure Two, https://dev.to/hosseinhezami/totp-authenticator-a-lightweight-php-library-for-secure-two-factor-authentication-428p

8. Beyond FTS5: Building Transactional Full-Text Search in TursoDB, https://turso.tech/blog/beyond-fts5

9. Hybrid full-text search and vector search with SQLite \- Alex Garcia, https://alexgarcia.xyz/blog/2024/sqlite-vec-hybrid-search/index.html

10. Pragma statements supported by SQLite, https://sqlite.org/pragma.html

11. How to Set Up SQLite with WAL Mode on Ubuntu \- OneUptime, https://oneuptime.com/blog/post/2026-03-02-how-to-set-up-sqlite-with-wal-mode-on-ubuntu/view

12. A new Markdown parser \- Tempest, https://tempestphp.com/blog/tempest-markdown

13. Preloading \- Manual \- PHP, https://www.php.net/manual/en/opcache.preloading.php

14. PHP performance tuning \- Upsun Developer, https://developer.upsun.com/docs/languages/php/tuning

15. Securing Session INI Settings \- Manual \- PHP, https://www.php.net/manual/en/session.security.ini.php

16. Runtime Configuration \- Manual \- PHP, https://www.php.net/manual/en/session.configuration.php

17. How to write a rock solid TOTP implementation?, https://security.stackexchange.com/questions/47979/how-to-write-a-rock-solid-totp-implementation

18. LLMS.txt adoption research report | Rankability Blog, https://www.rankability.com/data/llms-txt-adoption/

19. llms.txt Explained: The Spec, Real Adoption, and 2026 Data, https://macmdviewer.com/blog/llms-txt-guide

20. Standard Status | llms-full-txt.ru, https://llms-full-txt.ru/en/guides/standard-status/

21. llms.txt Explained (2026): Spec, Adoption, How to Ship One, https://codersera.com/blog/llms-txt-complete-guide-2026/

22. llms.txt: Semantic Conflict Resolution \- Grounding Page, https://groundingpage.com/facts/llms-txt/

23. AI Crawler User-Agent List | GPTBot, ClaudeBot, PerplexityBot & More, https://www.clickfrom.ai/tools/ai-crawler-user-agent-list

24. Overview of OpenAI Crawlers, https://developers.openai.com/api/docs/bots

25. AI crawlers & redirects: GPTBot, ClaudeBot, Perplexity 2026, https://www.captaindns.com/en/blog/ai-crawlers-redirects-handling-gptbot-claudebot-perplexitybot

26. Schema.org for AI Search: A JSON-LD Playbook for LLM Citations, https://alicelabs.ai/en/insights/schema-org-for-ai

27. DefinedTerm \- Schema.org Type, https://schema.org/DefinedTerm

28. Schema.org JSON-LD \- docs.researchdata.se, https://docs.researchdata.se/metadata/schema-org-json-ld/

29. ScholarlyArticle \- Schema.org Type, https://schema.org/ScholarlyArticle

30. SQLite FTS5 Extension, http://www3.sqlite.org/fts5.html

31. Full Text Search \- Complete Intro to SQLite, https://sqlite.holt.courses/lessons/performance-and-search/full-text-search

32. SQLite Full-text Search \- GeeksforGeeks, https://www.geeksforgeeks.org/sqlite/sqlite-full-text-search/

33. WCAG 2.2 New Success Criteria: Complete Implementation Guide, https://testparty.ai/blog/wcag-22-new-success-criteria

34. WCAG 2.2 Checklist: Complete 2026 Compliance Guide, https://www.levelaccess.com/blog/wcag-2-2-aa-summary-and-checklist-for-website-owners/

35. What's New in WCAG 2.2: The 9 New Success Criteria Explained, https://www.audioeye.com/post/whats-new-with-wcag-2-2/

36. What's New in WCAG 2.2 | Web Accessibility Initiative (WAI) \- W3C, https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/

37. WCAG 2.2 Level AA Success Criteria with Examples \- Medium, https://medium.com/@askParamSingh/wcag-2-2-level-aa-success-criteria-with-examples-2c525c029a78