Portfolio Portal
Capability

Inexis Digital sells websites to service businesses — plumbers, electricians, builders, dentists. To win the

4Provides2Consumes5Related capabilities
Explore next → Inexis Studios

Website Assessment Platform — Capability

The flagship capability — the platform’s canonical demonstration. Website Assessment is a cross-repo capability, not a single repo: intelligence authored in FIP → published as a versioned pack in intelproducts → executed by the engine in inexisstudios → evaluated against the website-intelligence-lab harness → consumed by outreachagent (and, declared, leadplatform). Follow it once and you understand the whole architecture — knowledge becoming customer value across every layer. Everything below is evidence-first; maturity is labelled honestly (✅ implemented · 🔶 in progress · ⏳ planned).

The problem

Inexis Digital sells websites to service businesses — plumbers, electricians, builders, dentists. To win the work, it has to show a prospect exactly where their current website underperforms for their industry, and then offer a replacement. Doing that consistently and defensibly — so the same site scores the same regardless of who assesses it, and so the diagnosis stands up in front of the customer — is the hard part.

Why existing approaches fail

  • Generic SEO graders score every site by the same checklist. They don’t know that trust signals matter more for a plumber than for a dentist, so their output isn’t a credible sales argument.
  • Manual audits are inconsistent between assessors and opinion-based — two people audit the same site and disagree — and they don’t scale past a handful of prospects.
  • AI-written audits sound confident but can’t be defended: there’s no repeatable rule behind the verdict, so the recommendation is opinion, not evidence.

Each failure has the same root: no codified, industry-specific intelligence, applied deterministically.

How this platform approaches it

The capability packages three things so any assessor produces the same result and the output can feed automated outreach:

  1. Codified industry intelligence — per-vertical conversion knowledge, published as a versioned pack.
  2. A deterministic scoring engine — rules decide and score; the same site always scores the same.
  3. Fact-grounded explanation — “Recommendations must not be based on AI opinion. AI may explain… after the rule-based recommendation has been selected” (assessment-engine-plan-v2.md §13). Nothing is ever auto-sent — a human approves before anything reaches a prospect.

The engine itself is domain-agnostic and pack-driven: it loads a runtime pack, so a new industry is a new pack, not new code. Positioning (inexisstudios/CLAUDE.md): “Preserve what has value. Improve what does not” — it is a sales/diagnostic wedge, not a generic SEO grader, and WordPress is treated as upgrade context, never a quality penalty.

The end-to-end journey

This is the canonical journey — a prospect’s website URL becoming an Inexis Digital customer, and the platform’s deterministic-then-AI-then-human spine running down the middle:

graph TD
  K["Industry knowledge<br/>authored in FIP"]:::plat --> PK["Assessment pack<br/>versioned · immutable"]:::prod
  URL["A prospect's website URL<br/>+ industry vertical"]:::src --> CR["Crawl the site<br/>Playwright"]:::app
  CR --> SC["Score against the pinned pack<br/>rules · 6 domains · 0–100"]:::app
  PK -->|scoring truth| SC
  SC --> FR["Findings + recommendations<br/>REC-001…015"]:::app
  FR --> AIN["AI explains — never decides"]:::app
  AIN --> HA{"Human approves<br/>nothing auto-sent"}:::gate
  HA --> RPT["Report<br/>/api/assessments/:slug"]:::app
  RPT --> COP["Commercial Opportunity Profile"]:::app
  COP --> OUT["Outreach + website-replacement proposal"]:::app
  OUT --> CUST["Inexis Digital customer"]:::ven
  CUST -. outcomes / usage signals .-> K
  classDef src fill:#f2f3f7,stroke:#c9cdda,color:#333;
  classDef plat fill:#e6f4ea,stroke:#1f7a3d,color:#333;
  classDef prod fill:#e6f4ea,stroke:#1f7a3d,color:#333;
  classDef app fill:#e6f4ea,stroke:#1f7a3d,color:#333;
  classDef gate fill:#fff3cd,stroke:#b8860b,color:#333;
  classDef ven fill:#eef0f4,stroke:#8079ff,color:#333;

In one sentence: point it at a service business’s website and it returns a defensible, industry-scored gap analysis that becomes the wedge to sell a new website. The dashed return edge — outcomes re-weighting the intelligence — is the planned Hermes loop (⏳ not built).

Architecture by layer — why the layering exists

The same journey, mapped to the platform’s layers. One capability crosses Layers 2 → 5, and each stage is a reusable layer in its own right — which is why the architecture is layered rather than one application:

graph TD
  IK["Industry knowledge"]:::src
  subgraph L2["Layer 2 · Intelligence Platform"]
    KI["Knowledge Intelligence — FIP authors"]:::d
  end
  subgraph L3["Layer 3 · Intelligence Products"]
    IP["Assessment package"]:::d
  end
  subgraph L4["Layer 4 · Applications"]
    ENG["Assessment engine"]:::d
    COP["Opportunity profile"]:::d
    OA["Outreach email"]:::d
    PROP["Website proposal"]:::d
  end
  subgraph L5["Layer 5 · Venture"]
    CUST["Inexis Digital customer"]:::v
  end
  IK --> KI --> IP --> ENG --> COP --> OA --> PROP --> CUST
  classDef src fill:#f2f3f7,stroke:#c9cdda,color:#333;
  classDef d fill:#e6f4ea,stroke:#1f7a3d,color:#333;
  classDef v fill:#eef0f4,stroke:#8079ff,color:#333;
  • Layer 2 (Intelligence Platform) authors the knowledge once — usable by any capability, not just this one.
  • Layer 3 (Intelligence Products) publishes it as a versioned, immutable pack: the engine pins a pack version as its scoring truth and never copies it (ecosystem Principle 3). This is why intelligence products exist — a pinned version is a reproducible contract, not a drifting prompt.
  • Layer 4 (Applications & Agents) runs the engine and the outreach agent against that contract.
  • Layer 5 (Venture) composes the result into Inexis Digital’s lead-gen. The venture composes the capability; it does not contain it.

What it produces — the output

Inputs: a website URL + optional industry vertical (10 AU verticals — plumber, electrician, builder, carpenter, landscaping, cleaning, physiotherapist, dentist, accountant, mortgage-broker; others fall back to “all industries” rules).

Outputs (the documented contract): an overall 0–100 score + band + maturity level 1–5, per-domain scores, evidence-backed findings, ranked recommendations (the recommended offer), a plain-English report, and downstream a Commercial Opportunity Profile.

Real artefacts (from source)

Artefact What it is Where
website-assessment-pack-v1 15 rules · 6 domains · scoring model · recommendation library REC-001…015 · maturity model 1–5 intelproducts ✅ published
Domain weighting trust 25 · conversion 22 · proof 15 · clarity 15 · mobile 13 · local-seo 10 → weighted 0–100 pack scoring model ✅
API contract POST /api/assessments {url, industry?} → 202 pending; poll GET /api/assessments/:slug (trimmed contract; ?full=1 = full PackAssessment) inexisstudios engine ✅
Job status sequence queued → crawling → scoring → recommendation_draft → ai_draft → ready_for_review → approved → sent (assessment-engine-plan-v2.md §8) engine ✅
COP schema v2 (frozen) evidence → diagnosis → recommendation(action) → solution_blueprint; recommendation.action ∈ {replace_website, monitor, manual_review, no_opportunity} outreachagent ✅
Expansion packs travel (sri-lanka-journey, WP-48B) and cleaning (WP-53) rule/runtime packs — proof the engine is domain-agnostic intelproducts ✅

Evidence boundary: the artefact contracts and structures above are documented in the source repos and shown here. A live sample assessment output for a specific real website is produced by the engine at runtime and is not reproduced in this portal — it lives in inexisstudios. This page does not fabricate one.

The business value

  • A positioned offer, not a patch. The score turns a free diagnostic into a reason to replace the website — the wedge Inexis Digital’s lead-generation depends on.
  • Consistent and defensible. Deterministic rules mean the same site scores the same regardless of assessor (pack-manifest.md) — the diagnosis holds up in front of the customer.
  • Scalable. An async crawl + score API replaces hand audits across 10 verticals.
  • Reusable across ventures. Domain-agnostic + pack-driven → new industries (cleaning, travel) are new packs, not new code — so the same engine serves Inexis Digital and Inbound Lanka.

Capability composition — why it’s reused, not rebuilt

This is the clearest example of capability composition across layers, and the reason capabilities are documented independently of ventures (ADR 0004):

graph LR
  SK["Shared Skills"]:::b --> KP["Knowledge Platform<br/>FIP authoring"]:::b
  KP --> PK["Assessment pack"]:::b
  PK --> ENG["Assessment engine"]:::b
  ENG --> OA["Outreach / COP"]:::b
  PK -. pinned submodule .-> LEAD["leadplatform ⏳ declared"]:::p
  ENG -. planned .-> FUT["Proposal gen · CRM · OpenClaw ⏳"]:::p
  classDef b fill:#e6f4ea,stroke:#1f7a3d,color:#333;
  classDef p fill:#eee,stroke:#bbb,stroke-dasharray:4 3,color:#333;

Because the capability is a pack + a service contract, a second venture reuses it by pinning the pack — not by re-implementing the engine. That is why capabilities exist independently of the ventures that consume them.

The decisions that shaped it

Only the decisions that directly explain this capability:

Decision Why it matters here Source
Deterministic scoring; AI explains The verdict is defensible and repeatable; AI narrates, never forms the opinion Principle 11 · assessment-engine-plan-v2.md §13
Human approval — nothing auto-sent No report or outreach reaches a prospect without a person approving it (ready_for_review → approved) Operating Principle O2
Versioned, immutable pack as the contract The engine pins a pack version → reproducible scores; the producer can improve the next version without breaking the last ADR 0003 · Principle 3
Capabilities are first-class, repo-independent The capability spans four repos but is owned and reasoned about as one thing ADR 0004
Domain-agnostic engine + pack-driven New verticals are new packs, not new code → cross-venture reuse pack-manifest.md

Evidence & maturity

Honestly labelled — the spec is mature, the engine core is real, cross-repo consumption is mostly mock.

Status What
✅ Implemented Engine core in inexisstudios (self-tests 40/40; async crawl → score → report; external API shipped); website-assessment-pack-v1 published & immutable; COP schema v2 frozen; outreachagent COP built; travel + cleaning expansion packs published
🔶 In progress Cross-repo consumption runs in mock mode by default in outreachagent (live wired, not operationally validated); the website-intelligence-lab harness is a Phase-1 seed (engine not yet run through it)
⏳ Planned Durable crawler queueing (Phase 3d); competitor benchmarking (§11); public assessment form (§7); full framework-versioning DB schema (§17); wiring leadplatform consumption; the Hermes learning loop to replace inference-derived weights with outcome-derived ones

Known limitations (stated in source): scoring weights are “review-gated defaults, not empirical coefficients” (scoring-model.md); the feedback/effectiveness loops are “documented, not implemented”; the crawler is not durable (in-memory; Phase 3d); pack v1 covers 10 AU verticals (others fall back to generic rules; health verticals route aggressive claims to human review).

Implementation detail (for engineers)

The deployable pieces across the contributing repos:

graph TD
    subgraph FIP["PersonalOps / FIP  ✅ (author)"]
        SRC["Per-vertical conversion intelligence,<br/>scoring priorities, rules (markdown)"]
    end
    subgraph IPR["intelproducts  ✅ (contract)"]
        PACK[("website-assessment-pack-v1<br/>15 rules · 6 domains · REC-001…015 · maturity 1–5")]
        RP[("rule-packs / runtime-packs<br/>travel · cleaning industry packs")]
    end
    subgraph ENG["inexisstudios  ✅ core (the engine)"]
        API["Cloudflare Pages Functions API<br/>POST/GET /api/assessments"]
        CRAWL["crawler-service<br/>Node + Playwright (separate deploy)"]
        SCORE["Scoring engine<br/>src/lib/assessment* · D1 + R2"]
        REPORT["Report UI / contract"]
        API --> CRAWL --> SCORE --> REPORT
    end
    subgraph LAB["website-intelligence-lab  🔶 (harness)"]
        RUNS[("Immutable provenanced Runs / benchmarks")]
    end
    subgraph CONS["Consumers"]
        OA["outreachagent → COP ✅ (mock default)"]
        LEAD["leadplatform ⏳ declared"]
    end
    SRC -->|authored + published| PACK
    PACK -->|pinned pack = scoring truth| SCORE
    RP -.domain packs.-> SCORE
    REPORT -->|/api/assessments/:slug| OA
    PACK -.vendored submodule.-> LEAD
    SCORE -.evaluated against.-> RUNS

Dependencies: the pinned pack (scoring truth), Cloudflare (Pages/D1/R2), Playwright crawler, the platform capability interface (resolveAssessmentPack, evaluateCommercialOpportunity, getCommercialOpportunity), COP schema v2 (frozen).