Skip to content

Advanced Patent Tracking

Patent tracking in the FCC ecosystem is not a single-repo concern. An invention sketched in ice_ext may appear as an architectural drawing in the FCC core repo, be mirrored into the ai-coe-docs (PHOENIX) consolidation tree, and show up again as a vocabulary extension in one of the ten constellation verticals. The Patent Claim Tracer (PCT) persona — introduced in v1.4.3 and elevated to its full governance scope in v1.5.0 — owns the traceability matrix that links every one of those surfaces back to a single canonical claim identifier.

This page is the auditor-facing reference for PCT. It explains the persona's Zachman cell, the claim-consolidation workflow, the cross-repo handoff pattern, where evidence lives in the FCC repo, and the exact grep patterns you would use to reconstruct the matrix from source during a cold audit.


The PCT persona, in one paragraph

PCT sits in the ARCHITECT/WHY cell of the Zachman matrix — the architect's row (design-level responsibility), the WHY column (motivation, rationale). The persona's single concrete artifact is docs/governance/patent-claim-matrix.md, a cross-ecosystem ledger in which every invention row cites source repo, source file, claim identifier, architectural evidence, prior-art status, FTO status, PHOENIX mirror status, and counsel-review status. The ledger is the single source of truth; every ecosystem repo reconciles against it.

PCT never modifies the underlying patent artifacts. It is an observer + mapper only — the pattern is identical to the way FCC's Documentation Strategist (DGS) observes docs without editing them. Counsel-status transitions are owner-gated and explicitly outside the automation scope.

For the full R.I.S.C.E.A.R. specification, see src/fcc/data/personas/patent_claim_tracer.yaml.


The three IP personas and their lanes

PCT never works alone. Three personas split the IP lane cleanly:

Persona Zachman cell Owns
PCT (Patent Claim Tracer) ARCHITECT/WHY Cross-ecosystem claim matrix + per-claim evidence ledger
IEA / IPEA (IP Evaluation Analyst, two cells) PLANNER/WHY + EXECUTIVE/WHY Invention-level evaluation, filing recommendation
IHL (Innovation Handoff Liaison) ARCHITECT/HOW PHOENIX (ai-coe-docs) mirror coordination and cross-repo PR orchestration

PCT feeds IEA/IPEA with claim-readiness signals; when an invention is counsel-ready, PCT hands off to IHL for the PHOENIX mirror. The escalation path is one-way (PCT → IEA → IHL → PHOENIX) with no back-edges allowed without an owner-gated exception.


The cross-repo pattern

The FCC ecosystem keeps patent evidence in nineteen per-codename subtrees. Each subtree carries the same directory shape; the PCT matrix simply points at the correct subtree for each invention.

Codename Patent subtree
FCC (this repo) docs/patent/
POLARIS (ice_ext) ice_ext/docs/patent/
AOME (aome_ext) aome_ext/docs/patent/
CONSTEL (constel_ext) constel_ext/docs/patent/
PAOM (paom) paom/docs/patent/
DISTILLER (distiller_ex) distiller_ex/docs/patent/
Ophiuchus through Caelum (10 verticals) {vertical}_ext/docs/patent/ (each)
ATHENIUM (l2_athenium) l2_athenium/docs/patent/
MNEMOSYNE (l2_mnemosyne) l2_mnemosyne/docs/patent/
LYRA (incubating) reserved, created with repo creation

Each subtree is structured identically:

docs/patent/
├── README.md           # subtree index
├── disclosure/         # invention disclosures
├── provisional/        # provisional claim drafts
├── utility/            # utility claim drafts
├── prior-art/          # prior-art landscape + search reports
├── fto/                # FTO-lite analysis
└── drawings/           # architectural drawings

The FCC repo has held its subtree since v1.3.9 (40,570 words, 20 provisional + 32 utility claims, FTO clean). The other subtrees landed progressively across v1.4.x and v1.5.0.


The consolidation workflow and QG-IP-CONS

QG-IP-CONS is the patent-consolidation quality gate in the PHOENIX extended registry. It is a tier_2 compliance-and-risk gate (see the Quality Gates Reference for the full tier taxonomy). QG-IP-CONS checks four propositions on every release candidate:

  1. Every invention disclosure in any subtree has a row in docs/governance/patent-claim-matrix.md.
  2. Every matrix row cites a source repo, source file, and claim ID.
  3. Every independent claim in the matrix has at least one architectural evidence citation (ADR, UML diagram, or code path).
  4. Every counsel-ready invention has an IHL handoff scheduled.

Propositions 1–3 are fully automated and run via the CI job patent-mirror-check.yml (weekly drift verification). Proposition 4 is partially automated — the scheduling call is a manual attestation by IHL, but the presence of the attestation is checked by CI.

If QG-IP-CONS fails, the release is blocked, exactly as any other tier_2 gate. An auditor reading the release dashboard can identify the failing proposition from the finding_code on the CI report.


Cross-repo consolidation is owner-gated

The consolidation workflow that actually pushes claim evidence into the PHOENIX (ai-coe-docs) tree is owner-approval-gated and has been so since v1.4.3. The FCC-side delegation scaffolding — PCT, IHL, the matrix template, and QG-IP-CONS wiring — is in place; the PR into PHOENIX is a separate action that requires explicit owner sign-off. This is by design. The ecosystem keeps FTO posture by decoupling "can we describe the invention cleanly" (automated) from "should we file / publish / dedicate" (counsel + owner judgement).

For an auditor, that means the following artifacts MUST exist and be internally consistent regardless of whether the PHOENIX push has occurred:

  • docs/governance/patent-claim-matrix.md (in-repo).
  • Every FCC subtree folder in docs/patent/.
  • Every invention row in the matrix cites docs/patent/disclosure/*.md or docs/patent/provisional/*.md or docs/patent/utility/*.md.
  • The CI contract data for patent-mirror-check.yml is present and up-to-date.

The absence of a PHOENIX push is not a finding; the inconsistency of the in-repo artifacts is.


Claim-tracing tooling

PCT's matrix uses a lightweight Markdown + YAML table that is greppable by design. The core grep patterns you will use in a cold audit are:

# Every invention ID mentioned anywhere in the FCC repo.
grep -rnE "INV-[0-9]{4}" docs/ src/

# Every independent claim declaration across the patent subtrees.
grep -rnE "^## Claim [0-9]+\b" docs/patent/

# Every matrix row referencing a specific invention.
grep -nE "^\| INV-[0-9]{4}" docs/governance/patent-claim-matrix.md

# Every ADR citation inside a matrix row.
grep -nE "ADR-[0-9]{3}" docs/governance/patent-claim-matrix.md

# Every claim-to-evidence gap finding (flagged by PCT, not silently
# approved).
grep -nE "\bevidence-gap\b" docs/governance/patent-claim-matrix.md

The invention-ID schema is INV-NNNN across every ecosystem repo. The schema is guaranteed by PCT via the "claim-ID governance" skill in the persona spec — duplicate IDs across repos are a tier_1 finding and block release.


Interpreting evidence-gap findings

When PCT cannot link a declared claim to architectural evidence in the canonical sources (ADR, UML, code path), the matrix row is marked evidence-gap rather than silently approved. This is the Humility principle in action — the discernment-matrix dimension on which PCT self-rates 4.4 and peer-rates 4.3.

An evidence-gap finding is not automatically a failure. It is an invitation to the owning persona (usually an architect-level persona like Blueprint Crafter or the architect pool lead) to either:

  1. Add the missing evidence in the owning repo (ADR, UML page, code reference), OR
  2. Withdraw the claim declaration.

Auditors should check that every evidence-gap row has an open governance issue tracking resolution. Long-standing gaps (older than one PI) are tier_2 compliance findings on QG-IP-CONS.


Escalation path to IHL

IHL (Innovation Handoff Liaison) is the persona that coordinates cross-repo PR orchestration against PHOENIX. The PCT → IHL handoff is the only sanctioned path from "claim is counsel-ready in FCC" to "claim is mirrored into PHOENIX". The handoff carries five fields:

Field Example
Invention ID INV-0042
Source repo l2_fcc_agent_team_ext
Counsel status ready_for_counsel
Proposed PHOENIX target path phoenix/patents/INV-0042/
Owner attestation @owner GitHub handle + timestamp

IHL refuses the handoff if any of the five fields is missing, which feeds back into the matrix as an incomplete-handoff finding.

For auditors: every invention with counsel_status = ready_for_counsel MUST have either a completed IHL handoff or a documented no-go rationale. The absence of either is a tier_2 finding.


Worked example — auditing INV-0042

Let us walk through an imaginary invention INV-0042 from the matrix side.

# 1. Pull the matrix row.
grep -nE "^\| INV-0042" docs/governance/patent-claim-matrix.md

# 2. Jump to the invention's disclosure.
cat docs/patent/disclosure/INV-0042.md

# 3. Walk the cited architectural evidence.
grep -rnE "INV-0042" docs/architecture/ docs/decisions/

# 4. Verify FTO status.
cat docs/patent/fto/INV-0042-fto-lite.md

# 5. Confirm PHOENIX mirror status (if applicable).
# The owner attestation lives in the matrix row, not in a separate file.

A pass looks like this:

  • Matrix row cites repo + file + claim ID.
  • Disclosure exists and describes the invention in plain language.
  • At least one ADR or architectural diagram references INV-0042.
  • FTO-lite artifact present and clean.
  • Owner attestation present in the matrix row (if ready_for_counsel).

A fail looks like any of the above missing, or internal inconsistencies between them (e.g., claim text contradicting the disclosure).


What PCT does NOT do

A common auditor misconception: PCT does not make filing recommendations. That is IEA / IPEA's lane. PCT also does not coordinate the external counsel review — that is owner-gated. And PCT does not push into the PHOENIX repo — that is IHL, and it too is owner-gated.

PCT's scope is precisely the matrix, the evidence citations, the gap findings, and the CI drift data. Anything beyond that is another persona's responsibility, and conflating them during an audit produces false findings.


Reading the CI drift data

patent-mirror-check.yml runs weekly and produces a JSON drift report under the workflow artifacts. The report carries four fields per invention:

Field Meaning
invention_id INV-NNNN
matrix_status present | missing | evidence-gap
subtree_status present | missing
mirror_status mirrored | pending | not_applicable

An auditor can pull the most recent drift report from the last successful CI run and sanity-check it against their independent grep-based reconstruction. The two should agree row-for-row. If they disagree, the drift report is authoritative until PCT reconciles — then the matrix is authoritative again.


Persona Direction Interaction
IEA (jv_governance) peer Supplies claim-readiness signals for JV IP evaluation
IPEA (governance) peer Supplies invention-level evidence pointers
IHL downstream Receives counsel-ready inventions for PHOENIX mirror
GCA (Governance Compliance Auditor) downstream Receives claim-to-evidence gap findings
FA (Forensic Auditor) downstream Receives matrix data for ecosystem-wide forensic sweeps

The IEA ↔ IPEA distinction trips up many first-time auditors. IEA lives in the jv_governance category and applies at the JV boundary (ATHENIUM, MNEMOSYNE). IPEA lives in the governance category and applies at the FCC core and constellation boundary. A single invention can route through either one but not both; the category-of-origin determines the lane.


Next steps

  • Read the Decision Archaeology page — the DAR persona reconstructs the rationale trail PCT cites in matrix rows.
  • Read the Quality Gates Reference for the full QG-IP-CONS tier classification.
  • Walk the R.I.S.C.E.A.R. Completeness page to see how fcc audit personas --strict treats the PCT YAML.
  • Consult the Codename Decoder for PHOENIX, POLARIS, and LYRA origin reasoning and canonical links.
  • Skim ADR-008 — POLARIS absorption and ADR-013 — Bidirectional federation conflict policy for the framework-level architectural decisions that PCT cites in matrix rows.
  • Open the PCT persona YAML at src/fcc/data/personas/patent_claim_tracer.yaml for the authoritative R.I.S.C.E.A.R. spec.
  • Review docs/personas/evolution/pct.md for the PCT evolution path (career milestones, first 90 days, escalation points).
  • Browse docs/tutorials/sample-prompts/persona-pct-prompts.md for ready-to-run prompts against the matrix.