P132 — AIEP — Product Mirror Manifest Extension

Publication Date: 2026-03-13 Status: Open Source Prior Art Disclosure Licence: Apache License 2.0 Author/Organisation: Phatfella Ltd Schema: AIEP_OS_SPEC_TEMPLATE v1.0.1 — https://aiep.dev/schemas/aiep-os-spec-template/v1.0.1

Framework Context

[0001] This disclosure operates within an Architected Instruction and Evidence Protocol (AIEP) environment as defined in United Kingdom patent application number GB2519711.2, filed 20 November 2025, and GB2519798.9, filed 20 November 2025, the entire contents of which are incorporated herein by reference.

[0002] The present disclosure extends the generic Well-Known Manifest Specification defined in P61 to the specific requirements of an AIEP SaaS product that exposes governed AI capabilities, a Learning List, an evidence rail, and a public API surface. It specifies the PieaMirrorManifest schema, the routes that serve it, the source filtering rules that govern which Learning List entries may be included, and the constraints on how external agents and other AIEP nodes may consume and ingest the manifest.

Field of the Disclosure

[0003] This disclosure relates to machine-readable product discovery endpoints exposed by AIEP-governed AI SaaS products, such that external AI agents, AIEP hub indexers, and other AIEP nodes can discover a product’s capabilities, evidence schema, public API surface, and qualified public sources without requiring authentication.

[0004] More particularly, the disclosure concerns: (a) the PieaMirrorManifest JSON schema extending P61 with product-specific sections; (b) the capabilities array as a machine-readable feature declaration; (c) the evidence_rail section declaring confidence tier vocabulary, source tier vocabulary, and governing patent references; (d) the learning_list section exposing public qualified sources while filtering tenant-private and lower-tier sources; (e) the aiep_alignment section anchoring the manifest to the AIEP Hub and patent corpus; and (f) the companion evidence_artefact_schema route serving the JSON schema for evidence rail artefacts.

Background

[0005] P61 defines a generic Well-Known Manifest format for AIEP-compliant sites. The generic format covers site identity, content hash binding, and mirror index linkage. A SaaS AI product requires additional sections: it has functional capabilities that other systems may wish to validate before integration; it has an evidence rail whose confidence tier vocabulary and patent anchors should be machine-discoverable; it exposes a public API whose route structure should be self-describing; and it maintains a Learning List whose publicly qualified sources should be discoverable for cross-system evidence exchange.

[0006] Without a product-specific extension of P61, a consuming AI agent encountering /.well-known/aiep/ on a Piea deployment cannot determine programmatically whether the product supports multimodal ingestion, substrate continuity, SSO, or Stripe billing — information that may be required before initiating a session or an integration.

[0007] The Learning List source exposure problem requires filtering. A Piea deployment may contain hundreds of tenant-private sources that must not appear in the public manifest. Only publicly qualified sources at tier 1 or tier 2 may be included. Without a formal filtering rule, implementers may inadvertently disclose private sources or conversely publish no sources at all, breaking the self-referential evidence ingestion use case.

Summary of the Disclosure

[0008] The PieaMirrorManifest is served at GET /.well-known/aiep/ with Content-Type: application/json. It is generated dynamically at request time and is not cached. The generated_at field records the ISO 8601 timestamp of generation. The manifest is structured as follows:

PieaMirrorManifest
├── aiep_mirror_version: "1.0"
├── product: { name, slug, version, description, domain, status }
├── capabilities: string[]
├── evidence_rail: { enabled, confidence_tiers, source_tiers, patent_refs }
├── api: { base_url, endpoints[] }
├── learning_list: { source_count, qualified_count, public_sources[] }
├── aiep_alignment: { hub_url, patent_refs, licence }
└── generated_at: ISO 8601

[0009] The capabilities array is a flat string array of machine-readable feature identifiers. The canonical capability identifiers for an AIEP SaaS product are:

[0010] The evidence_rail section declares: enabled: boolean; confidence_tiers — the ordered list of confidence tier vocabulary values (["qualified", "verified", "unverified", "community"]); source_tiers — the source tier vocabulary (["tier_1", "tier_2", "tier_3"]); and patent_refs — the array of AIEP patent numbers whose specifications govern the evidence rail behaviour of the product.

[0011] The api section declares the product’s public API surface. Each entry in endpoints comprises: method (HTTP verb); path (route pattern relative to base_url); description (one sentence); and auth_required (boolean). The base_url is environment-dependent — https://api.piea.ai in production, http://localhost:8787 in development. The manifest must include, at minimum, the following routes: GET /.well-known/aiep/ (this manifest), GET /.well-known/aiep/schema (evidence artefact schema), and POST /api/ask (governed query endpoint).

[0012] The learning_list section includes source_count (total sources in the registry), qualified_count (sources passing the qualification filter), and public_sources — an array of sources filtered to tier === "tier_1" OR tier === "tier_2" from qualified sources only. Each public source entry exposes url, label, tier, and category. Tenant-private sources must not appear regardless of tier. Sources at tier 3 or unclassified must not appear regardless of qualification status.

[0013] The aiep_alignment section declares: hub_url pointing to the AIEP Hub (https://aiep.ai); patent_refs listing the AIEP patent numbers whose implementations are live in the product; and licence describing the product’s licence terms.

[0014] The companion schema route GET /.well-known/aiep/schema serves the JSON Schema for an AIEP evidence artefact — the EVIDENCE_ARTEFACT_SCHEMA constant — enabling consuming agents to validate evidence artefacts they receive from the product’s API against the canonical schema declaration.

Detailed Description

[0015] PieaMirrorManifest Interface:

interface PieaMirrorManifest {
  aiep_mirror_version: "1.0";
  product: {
    name: string;
    slug: string;
    version: string;
    description: string;
    domain: string;
    status: "development" | "staging" | "production";
  };
  capabilities: string[];
  evidence_rail: {
    enabled: boolean;
    confidence_tiers: string[];
    source_tiers: string[];
    patent_refs: string[];
  };
  api: {
    base_url: string;
    endpoints: Array<{
      method: string;
      path: string;
      description: string;
      auth_required: boolean;
    }>;
  };
  learning_list: {
    source_count: number;
    qualified_count: number;
    /** Public qualified sources only — filtered to tier_1 / tier_2 */
    public_sources: Array<{
      url: string;
      label: string;
      tier: string;
      category: string;
    }>;
  };
  aiep_alignment: {
    hub_url: string;
    patent_refs: string[];
    licence: string;
  };
  generated_at: string;  // ISO 8601
}

[0016] Source Filtering Rule. The public_sources array is constructed by: (1) calling sourceRegistry.getQualified() to retrieve all sources that have passed the qualification pipeline; (2) filtering to entries where s.tier === "tier_1" || s.tier === "tier_2"; (3) mapping each qualifying entry to its { url, label, tier, category } fields, discarding all other fields including any tenant-identifying metadata. This rule ensures that tier 3 sources (lower confidence) and unqualified sources do not appear, and that source exposure is scoped by the platform’s evidence quality contract rather than by ad-hoc selection.

[0017] Dynamic Generation. The manifest must not be cached. Each request to /.well-known/aiep/ triggers a fresh call to buildMirrorManifest(). This ensures that: (a) the source_count and qualified_count reflect the current state of the source registry; (b) the status field reflects the current PIEA_ENV binding value; and (c) the generated_at timestamp is accurate at the time of serving. Serving a stale manifest may cause a consuming AI agent to operate with an outdated capability or source declaration.

[0018] Self-Referential Ingestion. A Piea deployment exposes its own /.well-known/aiep/ in its Learning List at tier 1. This enables Piea to ingest its own manifest as an evidence artefact and answer questions about its own capabilities using the evidence rail. This self-referential circuit is not circular — the ingested version is a historical snapshot, not the live manifest.

[0019] Distinction from P61 (Well-Known Manifest Specification). P61 defines the generic AIEP well-known manifest format applicable to any AIEP-compliant website or static deployment. P132 defines the product manifest schema for a governed AI SaaS product — extending P61 with capabilities, evidence_rail, api, learning_list, and aiep_alignment sections. A site implementing P61 without P132 is a compliant AIEP content site but not a compliant AIEP SaaS product mirror.

[0020] Relationship to External Mirror Ingestion. The manifest served under this specification may be consumed and persisted by other AIEP nodes using the external mirror ingestion mechanism (see P134 — Agent-Driven Mirror Ingestion). A consuming node fetches /.well-known/aiep/, validates the shape, computes SHA-256(manifestBody), and stores the record in its R2 mirror store under the key mirrors/{host}/manifest.json. This enables cross-node evidence exchange where each node’s public source declarations become available to the ingesting node’s evidence rail.