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:
- Every invention disclosure in any subtree has a row in
docs/governance/patent-claim-matrix.md. - Every matrix row cites a source repo, source file, and claim ID.
- Every independent claim in the matrix has at least one architectural evidence citation (ADR, UML diagram, or code path).
- 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/*.mdordocs/patent/provisional/*.mdordocs/patent/utility/*.md. - The CI contract data for
patent-mirror-check.ymlis 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:
- Add the missing evidence in the owning repo (ADR, UML page, code reference), OR
- 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.
Related personas and their touchpoints¶
| 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 --stricttreats 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.yamlfor the authoritative R.I.S.C.E.A.R. spec. - Review
docs/personas/evolution/pct.mdfor the PCT evolution path (career milestones, first 90 days, escalation points). - Browse
docs/tutorials/sample-prompts/persona-pct-prompts.mdfor ready-to-run prompts against the matrix.