Long Term Software and the Teleodynamic Ecosystem

Full report

On this page

Executive summary

The clearest commercial structure is a three-layer brand system. Long Term Software should be the buyer-facing consulting and productized-services site; Mike Kappel should remain the evidence library and technical proof archive; Teleodynamic should remain the R&D and methods layer. That separation is already implicit in the public material: Teleodynamic repeatedly describes itself as a public research framing and explicitly disclaims a finished runtime, certification, or biological equivalence; MikeKappel is built as a recruiter- and reviewer-readable proof system with resume, case studies, evidence maps, route QA, and machine-readable files; Long Term Software Solutions already frames itself as a “focused gateway” that routes buyers to the main consulting site.

Your strongest differentiator is not generic “AI consulting.” It is a rarer combination: deep Microsoft-stack modernization, SQL-heavy systems experience, parity validation, typed front-end architecture, and unusually rigorous AI governance, evidence, and review discipline. MikeKappel’s public work history shows enterprise delivery across .NET, SQL Server, TypeScript, Angular, AI-assisted engineering workflows, and parity-checking modernization; Teleodynamic adds a visible methodology for claim boundaries, review gates, auditable traces, and evidence-first growth. Together, they support a sharper market position: custom AI systems and modernization for business-critical software that cannot drift.

The current gap is message fit. Teleodynamic is intellectually distinctive but too research-dense for a first-time commercial buyer. MikeKappel is highly credible but still optimized more for hiring managers and technical reviewers than for consulting buyers. Meanwhile, the current Long Term Software root still appears unlaunched, with a default post on the homepage, while the stronger buyer-facing positioning already exists on the projects subpage and the Long Term Software Solutions microsite. Several project-page navigation targets on the main site currently return 404s, which undercuts trust if a prospect arrives there first.

The commercial opportunity is to translate your existing public proof into a small number of crisp, productized offers: an AI and modernization assessment, a zero-regression modernization blueprint, a source-governed AI knowledge system sprint, a custom AI workflow or internal copilot pilot, an AI evaluation and guardrail lab, and an ongoing architecture rescue retainer. Those offers map directly to what the current sites already prove: modernization and parity validation, AI documentation review, source-governed memory and handoff, evaluation/calibration, and API-grade publishing/integration infrastructure.

What the current sites already prove

Teleodynamic audit

Teleodynamic has unusually strong methodological discipline. Its core pages are not loose essays; they are organized into explicit research lanes for strategy, architecture, roadmap, evaluation, claim boundaries, resources, privacy, and agent-safe reading order. The site states in plain language that it is a public research interface, that claims remain bounded, and that human review is required before claim widening. The roadmap defines phases and “definition of done” in terms of resource-gated traces rather than hype. That gives you a serious foundation for premium messaging around trustworthy AI design, governance, and evaluation.

Its messaging strength is restraint. The claim-boundary FAQ explicitly says the site does not claim consciousness, biological equivalence, lossless glyph conversion, certification, or standards authority; the About page says Teleodynamic is the public experience site for research framing, not a finished runtime; the governance ledger tells agents not to transfer authority between linked domains. In a market full of AI overclaiming, that is a valuable commercial asset. It can be reframed for buyers as: “We do not sell magic. We design systems with evidence, boundaries, and review.”

The UX and information architecture are rigorous but cognitively heavy. The top-level menu is dense, highly domain-specific, and optimized for careful readers rather than executive buyers. Even the resource map is intentionally “a navigable research index” for humans and agents. This is excellent for R&D credibility, but it is not an ideal front door for a CIO, VP Engineering, or founder who wants to know in thirty seconds whether you can modernize a brittle application or ship a governed internal AI tool.

The visual design is stronger than many research sites because each major route has a distinct local SVG diagram and explicit route identity. The resources page says every major route now has its own recognizably different local visual system. That is a major asset to reuse on Long Term Software: not the jargon, but the pattern of “one visual per method or service.”

The technical stack clues strongly suggest a carefully controlled, custom public theme. Teleodynamic’s privacy page says the public surface uses static pages, static images, SVG diagrams, and read-only JSON assets; the same page says an audit of the active theme found no Google Analytics, Plausible, Umami, Matomo, tracking pixel, jQuery, or Bootstrap code, and it references WordPress hosting behavior for logs and admin/login cookies. The site also exposes agent-oriented and machine-readable routes. Publicly, that reads as a custom WordPress theme with a static-first, low-JS posture.

The main gaps are commercial translation and ecosystem sprawl. Teleodynamic links a wide constellation of adjacent domains and repeatedly emphasizes source-boundary separation. That is intellectually correct, but for a commercial buyer it risks fragmentation unless Long Term Software becomes the clear “commercial command center.” Teleodynamic should therefore move out of the homepage spotlight and into a Methods / Research section on the buyer site. Use it as proof of how you think, not as the primary thing you sell.

Mike Kappel audit

MikeKappel is your strongest public proof engine. It is not a generic portfolio; it is deliberately designed as a reviewer workflow. The site includes a career overview, experience timeline, case studies, evidence map, portfolio review guide, architecture notes, research dashboard, role-fit page, machine-readable files, and runtime QA surfaces. The evidence map explicitly connects resume language to projects, case studies, notes, JSON, and AI-readable files. That is rare and very persuasive for technical buyers.

Its content and message positioning are already close to your commercial sweet spot. The career page leads with “AI / .NET / SQL / TypeScript first,” while keeping Angular visible “where it belongs.” The experience page makes the same point and ties it to actual work history: Info724 for AI-assisted engineering and an Angular/TypeScript AI documentation review app, LongTerm Software for Angular on corporate tax software and CI/CD, and multiple roles centered on .NET, SQL Server, modernization, testing, and architecture. This is the backbone of a very credible consulting offer.

Its UX is unusually reviewer-friendly. The contact page puts email, phone, LinkedIn, GitHub, and resume first; the portfolio review guide tells reviewers exactly how to move from human summary to proof; the evidence map separates human review from AI-evaluator paths; the role-fit page includes an optional browser-local matcher and explicitly says the manual evidence paths remain available if automation is not useful. This is strong interaction design for trust.

Its visual design is dense, technical, and intentional. The site’s own llms.txt says the active visual direction is “Dense Corporate Command Layout,” recruiter-readable and evidence-bound. That design language fits proof pages well. It should be partially preserved on deep proof pages for Long Term Software, but simplified on top-level commercial pages. The homepage or service pages should have more air, fewer simultaneous options, and stronger business-outcome framing.

The technical stack clues are excellent. Publicly, the site identifies WordPress as the production runtime, says JavaScript is progressive enhancement, and exposes machine-readable review routes. A resume asset URL reveals a custom theme path. Runtime-health JSON shows package versioning, 14 REST endpoints, route-QA parity, direct-template fallback, and publicBootstrapDisabled: true. The route-QA contract lists custom endpoints for runtime health, report search, research search, profile, resume, evidence map, and dashboard functions, and the research dashboard documents package-local Playwright/Chromium QA, accessibility markers, compact-nav state checks, artifact parity, and separation of curated docs from stale noindex reports. This is all strong public evidence of a serious custom WordPress implementation.

Its main gap is angle of attack. MikeKappel still reads first as a highly disciplined individual architecture portfolio, not yet as a streamlined consulting product. That means your next site should not replace it; it should exploit it. Long Term Software should surface the commercial promise in plain English, and every important claim should have a secondary “See proof” route that lands on a MikeKappel artifact, case study, evidence map node, or resume-supported note.

Implication for Long Term Software

The current Long Term Software root should be treated as not yet ready for traffic, while the stronger commercial positioning already exists elsewhere. The root currently shows default WordPress starter content. By contrast, the projects area already describes itself as a curated buyer-facing proof ledger for enterprise AI infrastructure, data systems, protocols, monitoring, and scientific/semantic AI research, and the Long Term Software Solutions microsite already has clean buyer-language around modernization, AI systems, data-heavy platforms, and architecture assessment. Several project-page nav targets on the main domain currently 404, so the first priority is to consolidate the stronger messaging and remove broken paths before any serious outreach.

The right move is simple: port the best copy and IA from the microsite and projects section into the root domain, then treat MikeKappel as proof and Teleodynamic as method. That gives you a clean funnel: commercial promise first, proof second, research third.

Positioning, messaging, and service offers

Messaging architecture

Your commercial message should sit on three pillars.

The first pillar is safe AI for business-critical systems. MikeKappel’s work history repeatedly shows modernization with parity checks and production-behavior preservation, while Long Term Software Solutions already talks about “legacy rescue and zero-regression modernization.” That makes “safe AI adoption without breaking the system that already runs the business” more credible than generic transformation language.

The second pillar is evidence-first delivery. Teleodynamic’s public language centers on traces, review gates, no-op preference when evidence is weak, and refusal to widen claims without proof. MikeKappel mirrors that operationally with evidence maps, architecture notes, route QA, runtime health, stale-report boundaries, and machine-readable proof surfaces. Together, those support a distinctive message: “I build AI and modernization work that can be reviewed, tested, and handed off.”

The third pillar is custom engineering rather than tool theater. The public material proves actual architecture work across .NET, SQL Server, TypeScript, Angular, Python service boundaries, source-governed knowledge systems, and API-grade infrastructure. That is where you should lean hardest: not “we use AI,” but “we design the system around the AI so it is reviewable, secure, and useful.”

A strong homepage message set would look like this:

That message is directly aligned with your public proof: Long Term Software’s risk language, MikeKappel’s stack and experience framing, and Teleodynamic’s explicit claim-boundary posture.

Prioritized offers

The table below is a proposed commercial packaging, built from what the current public material already proves. The pricing ranges are planning estimates, not quotes.

These offers are not invented from thin air; they are strongly grounded in the existing evidence: parity validation and legacy rescue on the MikeKappel side, AI documentation review and Python/typed-service boundaries, source-governed AI memory and handoff patterns, and Teleodynamic’s evaluation, bounded-claim, and audit-trace framing.

Example case studies and portfolio templates

You already have enough public material to produce a compelling first wave of anonymized or lightly anonymized case studies.

These templates are all strongly defendable from current public evidence. MikeKappel documents AI documentation review, modernization, parity checks, and Python/typed-service boundaries; Long Term Software’s projects page already curates ecosystem proof around knowledge governance, evaluation, AI memory, and publishing infrastructure; Teleodynamic contributes the “why trust this” methods layer.

Recommended WordPress architecture for Long Term Software

Theme architecture and front-end strategy

For this project, the highest-value WordPress architecture is a custom hybrid theme: PHP-rendered marketing and proof pages for speed and crawlability, theme.json for design tokens and editor alignment, selective block support for content flexibility, and small JavaScript islands only where the UI genuinely needs it. WordPress’s own theme documentation distinguishes between classic and block themes, and theme.json works with both classic and block themes, which means you can keep precise PHP control without giving up modern design-token support.

For front-end interactivity, keep the default posture very close to your existing public sites: HTML-first, JavaScript as progressive enhancement, no jQuery, and no Bootstrap. That is already the live posture of the MikeKappel runtime and the Teleodynamic public theme audit. On the WordPress side, the modern native options are Script Modules and the Interactivity API, both introduced in WordPress 6.5 for front-end behavior without an old jQuery dependency model.

The practical JavaScript ladder should be:

That recommendation matches both official WordPress guidance and your own architecture patterns. WordPress says the REST API is the structured way to build new front-end experiences, while your Angular/RxJS reference repeatedly advocates SSR/SSG plus hydrated islands and keeping AI/data work behind APIs.

For CSS, I recommend a token-driven hybrid strategy: store brand-scale settings in theme.json, use CSS custom properties for primitives, add a small utility layer for spacing/layout/text rhythm, and write enduring components with BEM-style naming. Avoid CSS-in-JS for the PHP-rendered public theme; it adds complexity without much payoff here. Also avoid using a utility framework as the whole design system if the long-term goal is clear handoff, durable maintenance, and a custom visual voice. WordPress’s theme and coding-standard materials favor readable, maintainable cross-team code, which fits that choice.

Accessibility, SEO, and performance

Accessibility should be designed as a system, not patched later. WordPress’s theme handbook and coding standards explicitly tie theme work to WCAG-aware HTML, CSS, and JavaScript practices, and WordPress coding standards commit new and updated code to WCAG AA. Your own public sites already show unusually careful disclosure-state, focus-return, and compact-navigation QA postures, so accessibility can become another commercial proof point rather than just a compliance checklist.

For SEO, use direct server-rendered pages for all commercially important routes, keep page titles/H1s/canonical paths clean, and use structured data where it genuinely helps discovery, such as Organization, Breadcrumb, ProfilePage, FAQ, or Review/Case Study patterns where appropriate. Google’s SEO starter guide emphasizes helping search engines understand content created for users, and Google’s structured-data documentation explains that it uses structured data to understand pages and enable rich results.

Performance should be built around cache-first HTML delivery and minimal blocking work. WordPress’s own performance docs recommend server and reverse-proxy caching such as NGINX or Varnish, with page caching, object caching, and static-asset optimization as major performance levers. For the public site, that means cached HTML at the edge, a CDN for CSS/JS/fonts/images, Redis object cache, minimal third-party scripts, and a hard rule that the public theme stays light and mostly server rendered.

Image handling should rely on WordPress-native features first. WordPress has built-in responsive image support through srcset and sizes; its image functions encourage registered custom sizes rather than ad hoc browser scaling; and the loading-optimization APIs can add loading, fetchpriority, and decoding attributes. On the browser side, Google’s performance guidance recommends native lazy loading for noncritical images, modern formats such as AVIF or WebP, preloading LCP-critical assets, and deferring noncritical CSS.

In concrete terms, I would set these public-site targets:

Those targets line up with Google’s Core Web Vitals guidance and the kind of low-JS public posture your existing sites already demonstrate.

Security, scalability, CI/CD, and deployment

On security, the simplest rule is this: WordPress is the CMS and publishing surface, not the AI runtime. Keep all model calls server-side, never expose provider tokens to the browser, and keep business logic, route permissions, and AI integrations in plugins or mu-plugins rather than ad hoc theme code. WordPress’s hardening guide emphasizes updates, file permissions, backups, logging, and monitoring; the REST API docs require proper route registration and permissions; and Application Passwords provide revocable, hashed credentials for programmatic access.

Add a modern web-app security layer on top of that. OWASP’s CSP guidance describes Content Security Policy as effective defense in depth against XSS; the HTTP headers and secrets-management cheat sheets reinforce header hardening, secret rotation, and centralized storage. For Long Term Software, that means CSP, HSTS, secure cookies, least-privilege admin access, environment-variable or secret-manager storage, and no raw provider secrets in wp_options or localized JavaScript.

For AI-specific risk, use NIST AI RMF, the NIST Privacy Framework, NIST SSDF, and the OWASP LLM Top 10 as your governance baseline. Those sources give you a formal way to talk about trustworthiness, privacy risk, secure SDLC, prompt injection, insecure output handling, supply-chain issues, and model abuse. That matters because your public positioning is explicitly stronger when it is evidence-bounded and governance-aware.

For scalability, assume a stateless WordPress layer behind a load balancer or CDN, shared database, Redis object cache, and object storage for uploads. Horizontal scale is perfectly workable when page caching is strong and the app tier is kept mostly stateless. If later you need headless delivery for a separate marketing app, native WordPress REST plus an optional WPGraphQL layer are the right content APIs; but I would stay hybrid until there is a real need for a decoupled frontend. WordPress’s REST API is the native JSON foundation, and WPGraphQL’s own docs describe it as an extendable GraphQL schema for WordPress.

For CI/CD, copy the best pattern already visible on MikeKappel: versioned packages, route-QA contracts, runtime-health checks, accessibility probes, and separation between curated public docs and noindex research or stale material. That public QA posture is a differentiator. Pair it with Git-based deployments, Composer for PHP dependencies, Node-based asset builds, preview environments, smoke tests, Playwright for browser regression, PHPUnit or Pest for PHP, and deployment gates tied to artifact/version parity. The NIST SSDF provides the secure-SDLC frame; your own public proof already shows the practical implementation style.

Stack, folder structure, API design, and AI integration patterns

Recommended stack

For the main site, I recommend this stack:

The core architectural principle is the same one your own Angular/Python page already argues for: AI/data work stays behind APIs; the browser gets typed, quality-controlled payloads; and the public route renders useful meaning before hydration.

Folder structure

Use a clean separation between the public theme and durable business logic:

wp-content/
  themes/
    longterm/
      style.css
      theme.json
      functions.php
      screenshot.png
      templates/
        page-home.php
        page-services.php
        page-case-studies.php
        page-contact.php
        single-case_study.php
      template-parts/
        header/
        footer/
        sections/
        cards/
      patterns/
      inc/
        bootstrap.php
        setup.php
        assets.php
        navigation.php
        seo.php
        schema.php
        media.php
      assets/
        src/
          css/
            tokens.css
            base.css
            utilities.css
            components/
            pages/
          js/
            site.js
            modules/
            islands/
        dist/
      tests/
        playwright/
        phpunit/
  mu-plugins/
    lts-core/
      lts-core.php
      composer.json
      src/
        Admin/
        AI/
        ContentTypes/
        Domain/
        Http/
        Rest/
        Security/
        Telemetry/
        Support/
      templates/
      tests/

That structure follows three principles: theme code controls presentation; durable content models and integrations live in plugins; and testing is part of the package, not an afterthought. WordPress’s plugin handbook explicitly recommends custom post types in plugins rather than themes for portability, and REST support for custom content types should be enabled intentionally with show_in_rest.

Plugins to avoid and custom plugin patterns

For this project, I would avoid a plugin stack that fights the architecture. In practice that means avoiding page-builder-first site construction, overlapping cache/optimization plugins, catch-all AI plugins that obscure prompt/data flow, and convenience plugins that move durable content models into theme-dependent or opaque admin UIs. That advice follows from your own public strengths: explicit structure, reviewability, low-JS delivery, and proof surfaces that remain portable and inspectable.

A cleaner pattern is to use a small number of purpose-built plugins or mu-plugins, each with a bounded role:

This is also where you should keep machine-readable AI-reader boundaries. Both Teleodynamic and MikeKappel expose agent-facing routes and llms.txt or JSON discovery assets. Long Term Software should do the same, but with a simpler, explicitly commercial read order: homepage, services, cases, assessment, contact, and a clear statement that public machine-readable files do not authorize probing or automation beyond read-only discovery.

REST, GraphQL, and AI integration patterns

Use REST first for operational workflows. WordPress’s REST documentation makes clear that the REST API is the site’s structured JSON interface and is the foundation for modern WordPress interfaces. For Long Term Software, REST is the right fit for assessment submissions, search, case-study feeds, AI job creation, job-status checks, proof data, and internal admin surfaces. Routes should always have a unique namespace, register on rest_api_init, and include explicit permission_callback logic.

Use GraphQL optionally, not reflexively. WPGraphQL is a strong option if you later build a headless front-end or want more flexible content composition for read-heavy consumers. But it should be an optimization for a real use case, not the default complexity tax on day one. The first launch can be entirely successful with custom WordPress templates plus a small internal REST namespace.

For AI services, use a provider-adapter service layer outside WordPress. Good routing logic looks like this:

That recommendation is grounded in the providers’ own docs: OpenAI’s Responses API supports stateful interactions and tool use; its embeddings guide covers retrieval use cases; Azure OpenAI’s privacy docs describe grounding with your data while data remains in the designated source and say customer data is not used to retrain models; Amazon Bedrock describes IAM-based model access and states that it does not store or use customer data to train models; Google Cloud’s governance docs say customer data in Agent Search is not used to train foundation models, and Gemini Enterprise Agent Platform documents zero-data-retention options under defined configurations.

The best AI data-flow pattern for this site is:

source documents
  -> normalization / dedupe
  -> classification and redaction
  -> metadata + trust labels
  -> chunking / embeddings
  -> vector + metadata store
  -> retrieval
  -> model inference
  -> human review or policy gate
  -> publish / log / handoff

That pattern matches your existing public philosophy almost exactly: source-governed knowledge, typed contracts, review gates, bounded claims, and auditability.

Code snippets

The snippets below are designed to match the architecture above: custom WordPress theme, no jQuery, REST namespace in a plugin, and server-side AI integrations only.

Theme setup and asset entry points

<?php
/**
 * Theme bootstrap for Long Term Software.
 *
 * Responsibilities:
 * - register theme supports
 * - register navigation menus
 * - enqueue compiled CSS/JS without jQuery
 */

declare(strict_types=1);

/**
 * Registers theme supports and menus.
 *
 * @return void
 */
function lts_theme_setup(): void
{
    add_theme_support('title-tag');
    add_theme_support('post-thumbnails');
    add_theme_support('html5', [
        'search-form',
        'comment-form',
        'comment-list',
        'gallery',
        'caption',
        'style',
        'script',
    ]);

    register_nav_menus([
        'primary' => __('Primary Navigation', 'lts'),
        'footer'  => __('Footer Navigation', 'lts'),
    ]);
}
add_action('after_setup_theme', 'lts_theme_setup');

/**
 * Enqueues public assets with immutable file versions.
 *
 * Notes:
 * - No jQuery dependency is declared.
 * - Scripts are deferred and loaded in the footer.
 * - filemtime() helps cache-bust per deploy.
 *
 * @return void
 */
function lts_enqueue_assets(): void
{
    $theme_uri  = get_template_directory_uri();
    $theme_path = get_template_directory();

    $css_rel = '/assets/dist/site.css';
    $js_rel  = '/assets/dist/site.js';

    $css_ver = file_exists($theme_path . $css_rel)
        ? (string) filemtime($theme_path . $css_rel)
        : wp_get_theme()->get('Version');

    $js_ver = file_exists($theme_path . $js_rel)
        ? (string) filemtime($theme_path . $js_rel)
        : wp_get_theme()->get('Version');

    wp_enqueue_style(
        'lts-site',
        $theme_uri . $css_rel,
        [],
        $css_ver
    );

    wp_enqueue_script(
        'lts-site',
        $theme_uri . $js_rel,
        [],
        $js_ver,
        [
            'in_footer' => true,
            'strategy'  => 'defer',
        ]
    );
}
add_action('wp_enqueue_scripts', 'lts_enqueue_assets');

This uses the standard WordPress script-enqueue API and aligns with the public no-jQuery/no-Bootstrap posture already visible on your existing sites. WordPress documents wp_enqueue_script() for dependency-aware asset loading, and Script Modules are available where you want native ES-module loading.

Optional Script Modules pattern for small islands

<?php
/**
 * Registers and enqueues an ES module for a small interaction island.
 *
 * Use this for:
 * - assessment wizard steps
 * - disclosure widgets
 * - lightweight analytics-free interactions
 *
 * @return void
 */
function lts_enqueue_assessment_module(): void
{
    $src = get_template_directory_uri() . '/assets/dist/assessment.js';

    wp_register_script_module(
        'lts/assessment',
        $src
    );

    wp_enqueue_script_module('lts/assessment');
}
add_action('wp_enqueue_scripts', 'lts_enqueue_assessment_module');

WordPress added Script Modules in the 6.5 era and the Interactivity API documentation specifically points developers toward viewScriptModule and module-oriented front-end behavior.

REST endpoint for an internal AI workflow

<?php
/**
 * Plugin REST controller for AI assessment requests.
 *
 * Responsibilities:
 * - validate incoming assessment data
 * - enforce permissions
 * - dispatch a server-side AI request
 * - return a bounded JSON response
 */

declare(strict_types=1);

final class LTS_Ai_Assessment_Controller
{
    private const NAMESPACE = 'lts/v1';

    /**
     * Hooks controller registration into WordPress.
     *
     * @return void
     */
    public function register(): void
    {
        add_action('rest_api_init', [$this, 'register_routes']);
    }

    /**
     * Registers AI assessment routes.
     *
     * @return void
     */
    public function register_routes(): void
    {
        register_rest_route(
            self::NAMESPACE,
            '/ai/assessment',
            [
                [
                    'methods'             => WP_REST_Server::CREATABLE,
                    'callback'            => [$this, 'create_assessment'],
                    'permission_callback' => [$this, 'can_create_assessment'],
                    'args'                => [
                        'system_summary' => [
                            'required'          => true,
                            'sanitize_callback' => 'sanitize_textarea_field',
                            'type'              => 'string',
                        ],
                        'primary_stack' => [
                            'required'          => false,
                            'sanitize_callback' => 'sanitize_text_field',
                            'type'              => 'string',
                        ],
                        'risk_profile' => [
                            'required'          => false,
                            'sanitize_callback' => 'sanitize_text_field',
                            'type'              => 'string',
                        ],
                    ],
                ],
            ]
        );
    }

    /**
     * Determines whether the current request may create an assessment.
     *
     * Public-site recommendation:
     * - if anonymous traffic is allowed, use rate limiting + CAPTCHA + queueing
     * - if authenticated staff only, require a capability check
     *
     * @param WP_REST_Request $request Incoming request.
     * @return bool
     */
    public function can_create_assessment(WP_REST_Request $request): bool
    {
        return current_user_can('edit_posts');
    }

    /**
     * Creates an assessment by forwarding a bounded payload to a server-side AI service.
     *
     * @param WP_REST_Request $request Incoming request.
     * @return WP_REST_Response|WP_Error
     */
    public function create_assessment(WP_REST_Request $request)
    {
        $payload = [
            'system_summary' => (string) $request->get_param('system_summary'),
            'primary_stack'  => (string) $request->get_param('primary_stack'),
            'risk_profile'   => (string) $request->get_param('risk_profile'),
            'trace_id'       => wp_generate_uuid4(),
        ];

        $response = wp_remote_post(
            LTS_Secrets::required('LTS_AI_GATEWAY_URL') . '/assessment',
            [
                'timeout' => 20,
                'headers' => [
                    'Content-Type'  => 'application/json',
                    'Authorization' => 'Bearer ' . LTS_Secrets::required('LTS_AI_GATEWAY_TOKEN'),
                ],
                'body'    => wp_json_encode($payload, JSON_THROW_ON_ERROR),
            ]
        );

        if (is_wp_error($response)) {
            return new WP_Error(
                'lts_ai_gateway_error',
                __('The AI gateway request failed.', 'lts'),
                ['status' => 502]
            );
        }

        $status = wp_remote_retrieve_response_code($response);
        $body   = json_decode((string) wp_remote_retrieve_body($response), true);

        if ($status >= 400 || !is_array($body)) {
            return new WP_Error(
                'lts_ai_invalid_response',
                __('The AI gateway returned an invalid response.', 'lts'),
                ['status' => 502]
            );
        }

        return new WP_REST_Response(
            [
                'data' => $body['data'] ?? null,
                'meta' => [
                    'trace_id' => $payload['trace_id'],
                    'source'   => 'lts-ai-gateway',
                ],
            ],
            200
        );
    }
}

(new LTS_Ai_Assessment_Controller())->register();

This follows the official REST approach: unique namespace, route registration on rest_api_init, and explicit permission_callback handling.

Secure API key handling

<?php
/**
 * Centralized secret reader.
 *
 * Guidance:
 * - store secrets in environment variables or an external secret manager
 * - never embed provider keys in JS
 * - never store production secrets in theme settings for public use
 */

declare(strict_types=1);

final class LTS_Secrets
{
    /**
     * Returns a required secret value from environment or wp-config constants.
     *
     * @param string $name Secret name, e.g. LTS_AI_GATEWAY_TOKEN.
     * @return string
     * @throws RuntimeException Thrown when the secret is missing.
     */
    public static function required(string $name): string
    {
        $value = getenv($name);

        if ($value === false && defined($name)) {
            /** @var string $constantValue */
            $constantValue = constant($name);
            $value = $constantValue;
        }

        if (!is_string($value) || $value === '') {
            throw new RuntimeException(sprintf('Missing required secret: %s', $name));
        }

        return $value;
    }
}

For WordPress-originating integrations that need authenticated API access, Application Passwords are preferable to sharing a main account password because they are revocable, per-application credentials stored hashed and designed for programmatic use. For external AI-provider secrets, follow centralized secret-management practices rather than storing keys in public runtime code paths.

Roadmap, sitemap, wireframes, and budgets

Implementation roadmap

A practical first release can be delivered in six phases.

A good launch principle is commercial surface first, proof second, research third. That means the first shippable release does not need every ecosystem concept exposed. It needs the clearest buyer path, with strong links outward to evidence and method.

Budget ranges

These ranges assume the traffic profile, hosting constraints, and internal content support are still unspecified.

A continuing support or architecture retainer after launch would typically sit in the $4,000–$18,000+ per month range depending on whether the work is mostly content/QA, ongoing modernization oversight, or active AI product development.

Sitemap and wireframe suggestions

The public sitemap should be much simpler than MikeKappel and much more buyer-oriented than Teleodynamic:

Home
Services
  AI and Modernization Assessment
  Zero-Regression Modernization
  Custom AI Apps and Workflows
  Source-Governed Knowledge Systems
  AI Evaluation and Guardrails
  Data Systems and Integrations
Process
Case Studies
Projects and Proof
Methods
About
Contact
Optional utility layer
  Downloads
  FAQ
  Privacy
  llms.txt / AI agent manifest

Use Projects and Proof as the bridge to MikeKappel, and use Methods as the bridge to Teleodynamic. That way the commercial site stays plain-English and task-oriented, while the deeper material stays available for serious reviewers.

The homepage wireframe should prioritize one story:

Service-page wireframes should all follow one pattern: buyer problem, what you do, what gets delivered, what it looks like in practice, proof links, FAQ, CTA. Case-study pages should use the MikeKappel proof posture but with more visible business outcomes up top. Connect deep notes, evidence maps, or PDFs below the fold rather than putting technical density in the lead.

Mermaid diagrams

flowchart TD
    A[Long Term Software] --> B[Services]
    A --> C[Case Studies]
    A --> D[Projects and Proof]
    A --> E[Methods]
    A --> F[Contact and Assessment]

    D --> G[Mike Kappel evidence library]
    E --> H[Teleodynamic research and methods]

    F --> I[Assessment workflow]
    I --> J[CRM and scheduling]
    I --> K[AI service layer]

    K --> L[OpenAI or Azure OpenAI]
    K --> M[Bedrock or Vertex]
    K --> N[SQL and vector data]
    K --> O[Audit logs and review records]

The architectural principle here is clear boundaries: Long Term Software sells, Mike Kappel proves, Teleodynamic explains the method. That boundary discipline is already explicit in the public ecosystem materials.

gantt
    title Proposed implementation timeline
    dateFormat  YYYY-MM-DD
    axisFormat  %b %d

    section Strategy
    Discovery and messaging           :a1, 2026-06-16, 10d
    IA and wireframes                 :a2, after a1, 10d

    section Build
    Theme and plugin foundation       :b1, after a2, 20d
    Content and case study production :b2, after a2, 20d
    Assessment and AI integration     :b3, after b1, 15d

    section Launch
    QA hardening and performance      :c1, after b2, 10d
    Production launch                 :c2, after c1, 3d

This sequencing assumes you do not wait to perfect the entire ecosystem before launching the buyer surface. Get the commercial core live first, then deepen the proof and methods layers. That is the fastest path to a coherent market presence.

Open questions and limitations

A few limits remain important.

Publicly, Teleodynamic provides strong clues of a custom low-JS WordPress theme, but I did not rely on raw source-code inspection beyond what the site itself states in privacy and public pages, so stack observations for that site are necessarily framed as public technical clues, not a definitive build manifest.

The current Long Term Software domain appears only partially built. The commercial recommendations above therefore assume you will replace the current root homepage and resolve broken navigation before sending meaningful traffic there.

The pricing and timeline ranges are proposed planning estimates, not market-survey claims or fixed bids. They should be refined once you decide whether the first release is strictly marketing plus proof, or whether it also includes a functional AI assessment flow and external service layer.