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)
Key topics
- SEO / Portfolio / Public Site
- SEO
- Portfolio
- Public Site
- AI
- Agentic Web
- AEO
- GEO
- .NET
Research provenance
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.
| Layer | Technology | Justification and Role |
|---|---|---|
| Operating System | Linux (Debian/Ubuntu LTS) | Provides a stable, auditable, and widely supported base environment. |
| Web Server | Nginx | Handles static file delivery, compression (Brotli/Gzip), TLS termination, and reverse-proxying to PHP-FPM. |
| Application Logic | PHP 8.4 | Executes server-side routing, Markdown parsing, and database interaction. Utilizes advanced OPcache and Just-In-Time (JIT) compilation for extreme performance1. |
| Database | SQLite 3 | Zero-configuration, serverless, file-backed database3. Facilitates complex relational querying and internal full-text search without the overhead of a daemonized database process. |
| Content Format | Markdown (CommonMark/GFM) | A highly durable, machine-readable flat-file format for authoring research. Parsed via zero-dependency pure-PHP parsers4. |
| Search Engine | SQLite FTS5 | Native Virtual Table extension enabling high-performance, BM25-ranked full-text search directly within the SQLite file3. |
| Authentication | Pure 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
- Zero-Dependency Architecture: Strategy for sovereign web infrastructure.
- Geopolitical Risk Matrix: Analysis of semiconductor supply chains.
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 Element | Semantic 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 Answer | A specific \<div class="executive-summary"\> formatted for immediate extraction by AI Overviews. |
| Definitions | \<dfn\> tags wrapping defined terminology throughout the text. |
| Major Claims | Semantic \<blockquote\> or distinct \<section\> tags outlining core assertions. |
| Supporting Citations / Primary Sources | Sidenotes 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 Level | A visual and semantic \<span class="badge confidence-high"\> indicating the epistemological weight of the research. |
| Revision History | A \<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.
11.1 Immutable Deployments via Symlinks
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.
| Deliverable | Resolution / Location |
|---|---|
| 1\. Tech Stack | Linux, Nginx, PHP 8.4, SQLite 3, Markdown (Zero external dependencies). |
| 2\. Directory Structure | Detailed in Section 3.1. Isolates public assets from core application logic and data. |
| 3\. Request Lifecycle | Detailed in Section 3.2. Nginx static cache \-\> PHP Front Controller \-\> SQLite \-\> View rendering. |
| 4\. Content Model | Hybrid Model: Authored in Markdown, synced to SQLite for querying and search. |
| 5\. Database Schema | Detailed in Section 2.1. Includes authors, articles, and citations tables. |
| 6\. Research Schema | Detailed in Section 7.1 and 7.2. Utilizes ScholarlyArticle and Claim JSON-LD. |
| 7\. Routing Architecture | Regex-based PHP front controller mapping clean URLs to specific SQLite queries. |
| 8\. Caching Strategy | Nginx serves pre-rendered HTML. PHP OPcache preloads classes. Static assets served with immutable cache headers. |
| 9\. Security Checklist | CSP (no unsafe-inline), HSTS, CSRF tokens, strict session cookies, TOTP admin auth. |
| 10\. SEO Checklist | Semantic HTML, automatic XML sitemaps, canonical tags, zero CLS, sub-100ms TTFB. |
| 11\. AEO Checklist | JSON-LD injection, semantic \<blockquote\> for claims, \<dfn\> for terms, concise answers mapped to specific HTML classes. |
| 12\. GEO Checklist | Implementation of llms.txt, permissive robots.txt for AI agents, machine-readable .md endpoints. |
| 13\. Structured Data | Example JSON-LD provided in Section 7.2 covering ScholarlyArticle and DefinedTerm. |
| 14\. Sitemap Architecture | sitemap\_index.xml pointing to categorized sitemaps containing \<lastmod\> dates. |
| 15\. Favicon Spec | favicon.ico, icon.svg, apple-touch-icon.png, and manifest.webmanifest. |
| 16\. Deployment Workflow | Atomic symlink deployments via Git post-receive hooks. |
| 17\. Backup Strategy | SQLite Online Backup API, Git repository cloning, and off-site encrypted rsync. |
| 18\. Accessibility | WCAG 2.2 AA compliant focus appearance (2.4.13), target size (2.5.8), and accessible authentication (3.3.8). |
| 19\. Performance Budget | TTFB \< 100ms, LCP \< 1.5s, CLS \= 0\. Achieved via JIT, static caching, and system fonts. |
| 20\. External Dependencies | Zero. No external CDNs, JS frameworks, hosted fonts, analytics, or search services. |
12.1 Recommended Phased Implementation Order
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