# Notes — Patrick Colm Audley *Working notes, position pieces, and short essays. Cross-posted from various platforms so they outlive any one of them.* Author: [Patrick Colm Audley](https://patrickaudley.com/) · License: Creative Commons BY-NC-SA CAv2.5 · Canonical homepage: Each post is also available as standalone Markdown at `/posts/{slug}.md`. --- ## GMEOW: a reasoning-centric super-vocabulary for digital existence **Date:** 2026-06-04 · **Cross-posted from:** [LinkedIn](https://www.linkedin.com/feed/update/urn:li:share:7468346496736772097/) · **Tags:** `ontology-engineering`, `semantic-web`, `owl`, `rdf`, `linked-data`, `knowledge-graphs`, `knowledge-representation`, `ontology-alignment`, `local-first`, `ai-agents` > A new ontology project: GMEOW, the Global Metadata and Entity Ontology for the Web — a reasoning-centric, OWL 2 DL, gUFO-grounded super-vocabulary for a person's or organization's digital existence. It mints canonical terms and aligns outward to FOAF, REL, DOAP, GEDCOM, PROV-O, ORG, schema.org, vCard and Wikidata, treating provenance, confidence, temporal validity, and coreference as first-class concerns. I've started a new ontology project: **GMEOW** — the Global Metadata and Entity Ontology for the Web. The design goal is a reasoning-centric, OWL 2 DL, gUFO-grounded super-vocabulary for modelling a person's or organization's digital existence. This came out of a practical problem: once you start trying to build local-first agents over real personal or organizational memory, you quickly run into vocabulary fragmentation. Contacts, email, documents, projects, notes, legal agreements, genealogy, publications, accounts, calendars, and social presence all have their own mature-but-isolated ways of describing the world. FOAF, REL, DOAP, GEDCOM, PROV-O, ORG, schema.org, vCard, Wikidata, and others all carry useful structure — but none of them gives you the whole shape. GMEOW's approach is to mint canonical terms and align outward. So rather than rewriting source data, it creates a coherent upper layer where surface vocabularies can map into a common model. The ontology is grounded in gUFO, checked against OWL 2 DL constraints, and built around the idea that provenance, confidence, temporal validity, and coreference are first-class modelling concerns. The project grows by slices. The first slice is entities + contacts. Each slice adds canonical terms, SSSOM alignment tables, fixtures, and coverage reporting so progress is measurable against real data rather than wishful thinking. The toolchain is also part of the point: validate, reason, mappings, Wikidata checks, metadata, content negotiation, docs, build artifacts, and publishing support all need to run cleanly. Ontologies should have CI discipline too. I'm particularly interested in feedback from people working with OWL/RDF, upper ontologies, ontology alignment, semantic-web publishing, personal data stores, provenance models, local-first AI, and agent memory. Where have you seen personal or organizational knowledge graphs break because the vocabulary layer was too thin? The repo is open: [gmeow-ontology](https://github.com/Blackcat-Informatics/gmeow-ontology). *Standalone: · Canonical anchor: * --- ## Gmeow: your mailbox is agent memory, keep it local **Date:** 2026-05-24 · **Cross-posted from:** [LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:7464480186072285184/) · **Tags:** `open-source`, `ai-agents`, `gmail`, `mcp`, `local-first`, `semantic-search`, `knowledge-graphs`, `archives` > The recurring problem with useful personal agents is that the context they need already exists, but not in the tidy place a demo would like it to be. It is in mail. gmeow makes that mailbox substrate locally useful through loopback REST, MCP, PostgreSQL, semantic search, attachment sidecars, object storage, and a local knowledge graph. The recurring problem with useful personal agents is that the context they need already exists, but not in the tidy place a demo would like it to be. It is in mail. Not just messages, either. It is in labels, half-forgotten attachments, old project threads, invoices, flight changes, account notices, side-channel decisions, introductions, one-off commitments, and all the little “do you remember when...” fragments that make a mailbox closer to institutional memory than correspondence. For a working agent, Gmail is not an inbox. It is a substrate. `gmeow` is my attempt to make that substrate locally useful without turning it into yet another cloud import pipeline. The design is deliberately boring in the places that should be boring: authenticate to Gmail, hydrate the mailbox, cache the useful structure locally, expose a loopback API, and give agents an MCP endpoint they can query without being handed the keys to the entire account. Under the hood it keeps a PostgreSQL catalogue of labels, threads, headers, MIME structure, categories, graph triples, jobs, sync state, and embedding chunks; stores payloads in a BLAKE3 content-addressed object store; builds attachment sidecars; and layers lexical search, semantic search, and graph traversal over the result. The important boundary is this: `gmeow` is not a hosted mail intelligence service. It is for trusted single-user local systems. By default it binds to `127.0.0.1`. It does not pretend to be an Internet-facing application with a half-baked auth layer stapled on afterwards. If you expose it to an untrusted network, you are outside the threat model. That constraint is not an inconvenience; it is the point. The agent-facing surface is the part I care about most. A local coding or research agent should be able to ask questions like: “Find the thread where we decided on the migration plan.” “Show me attachments from this vendor that mention renewal.” “Which people, projects, and topics are connected to this message?” “Summarise the recent unread messages in this category.” “Archive this after recording the relevant metadata.” That is a very different shape from building a mail client. A mail client is an interface for a human sitting at the glass. `gmeow` is plumbing for agents operating beside the human: search, reads, labels, contacts, categories, attachment metadata, archive state, semantic lookup, and graph exploration through REST and MCP. The graph piece is where this starts to get interesting. Mail is full of latent structure: people, organisations, projects, documents, obligations, recurring operational patterns. Some of that structure is explicit in headers and labels. Some of it only shows up once you extract text, classify categories, embed chunks, and let the relationships accumulate. I do not want an agent merely doing keyword search over my mailbox. I want it to build a usable local map. There is also an archival motive here. I have never liked systems where the only complete copy of a working record lives behind someone else's product boundary. `gmeow` keeps the raw RFC822 path in mind, exposes a read-only IMAP service over cached archive objects, and treats attachments as first-class local objects rather than opaque blobs dangling off an API response. If a mailbox is part of your long-term memory, it should be possible to preserve it with some dignity. This is the first member of a pattern I expect to reuse across the Google surface area. Gmail is the obvious starting point because mail is dense with context, but the same local-first shape should work for Drive, Calendar, and the other services agents keep needing to reason about. Each service gets its own small daemon, local cache, object model, MCP tools, and deliberately narrow trust boundary. The cat may end up carrying a different object each time. Current status: early, opinionated, and useful enough to start dogfooding. Python, PostgreSQL, FastAPI-shaped edges, pgvector for embedding chunks, local object storage, optional SOPS-backed secrets, service-account delegation or user OAuth, and compact TOON responses by default for MCP clients that do not need JSON-shaped ceremony. If you are building local agents that need to reason over real mail instead of toy corpora, kick the tires. The repo is open, rough edges included: [gmeow](https://github.com/paudley/gmeow). *Standalone: · Canonical anchor: * --- ## Agentic coding needs human sign-off tied to physical reality **Date:** 2026-05-21 · **Cross-posted from:** [LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:7463256842350022656/) · **Tags:** `ai-governance`, `software-security`, `ai-coding`, `appsec`, `zero-trust`, `devsecops`, `coding-ethos` > As AI coding agents transition from passive autocomplete tools to autonomous contributors executing entire feature branches, we are racing toward a massive security blind spot: how do we prove a real human actually reviewed and verified agent-generated code before it hits production? As AI coding agents transition from passive autocomplete tools to autonomous contributors executing entire feature branches, we are racing toward a massive security blind spot: How do we prove a real human actually reviewed and verified agent-generated code before it hits production? This is not a *new* problem, but it is definitely a more *urgent* one now. In my project, [coding-ethos](https://github.com/paudley/coding-ethos), we focus heavily on building policy-as-code guardrails for AI agents — using Common Expression Language policies, Git hooks, sandboxing, and Model Context Protocol servers to ensure autonomous agents cannot ship code that violates your team's standards, even if you are not in the loop. But even the most robust automated gates are only half the battle. The ultimate layer of defence-in-depth requires real eyes reviewing critical code. In a fully agentic workflow, traditional SSH or GPG commit signing is no longer sufficient and is often automated. If an agent process or local environment is compromised, or shifted via a sophisticated prompt injection, those stored credentials can be misdirected. Or people can just be lazy. We need a zero-trust developer confirmation model that is cryptographically tied to physical reality: **Biometrically verified:** fast, low-friction validation, such as Face ID or Touch ID, proving a living, authorized developer is actively at the glass. **Temporally verified:** ensuring human approval occurs precisely during the commit window, eliminating replay attacks. **Geophysically verified:** confirming that the developer's physical location aligns with expected telemetry and trusted boundaries. When an autonomous agent proposes a critical architectural change, the final gate should not just be a green checkmark from a CI pipeline. It needs to be an un-spoofable human assertion. I am currently designing this exact defence layer for coding-ethos, and I want to open up the floor to the network: How is your engineering team drawing the line between automated policy enforcement and hard human sign-off? As agents handle larger chunks of the codebase, how do we prevent reviewer fatigue from turning human verification into an automatic rubber stamp? Let's discuss. I am actively looking to take this specific verification framework from a design pattern into a live platform integration. If you are building a biometric fast-ID product or running an enterprise software supply-chain security platform and want to explore a trial integration with coding-ethos, [let's connect](#contact). *Standalone: · Canonical anchor: * --- ## Engineering principles should be runnable policy, not slide-deck nostalgia **Date:** 2026-05-01 · **Cross-posted from:** [Reddit (r/GeminiCLI)](https://www.reddit.com/r/GeminiCLI/comments/1t146xk/keep_your_agents_in_line_codingethos_turns/) · **Tags:** `ai-agents`, `policy-as-code`, `coding-ethos`, `mcp`, `static-analysis` > If your team's standards live in a slide deck, your AI agents will violate them. coding-ethos compiles one YAML file into linter configs, git hooks, agent prompts, and an MCP server so the rules cannot drift between human and machine readers. The thing I keep running into with multi-agent setups is that the engineering principles a team actually cares about — how to handle errors, when to wrap shell calls, what counts as a critical path — live in a wiki page or a slide deck nobody reads. That's already a problem for humans; for an LLM agent it is a guarantee of policy violation. [coding-ethos](https://github.com/paudley/coding-ethos) is the position I've taken: those principles belong in a single `coding_ethos.yml` file, and from that one file the build emits everything that needs to know about them — `CLAUDE.md` / `GEMINI.md` agent instructions, Ruff / Pyright / golangci-lint configs, compiled Go pre-commit hooks, agent tool-use guards, and an Model Context Protocol server the agent can query at runtime. The key invariant: the engine that writes the markdown rules is the exact same engine that evaluates Common Expression Language expressions at the git-hook level. They *cannot* drift. If the hook denies an action, the agent gets back a structured `skill_id` hint instead of a generic exit code — so the feedback loop closes inside the agent's own context rather than landing on a human's screen. Heavily opinionated, currently slanted toward Python and Go, in active development. Posted on r/GeminiCLI with worked examples; [read the original thread](https://www.reddit.com/r/GeminiCLI/comments/1t146xk/keep_your_agents_in_line_codingethos_turns/) if you want the implementation walk-through, and feature requests are welcome on the [repo](https://github.com/paudley/coding-ethos). *Standalone: · Canonical anchor: * --- ## Standard Graph Neural Networks need curved semantic manifolds **Date:** 2026-04-22 · **Cross-posted from:** [LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:7458177770238681088/) · **Tags:** `topological-data-analysis`, `graph-neural-networks`, `manifold-learning`, `knowledge-representation` > Standard GNNs are structurally constrained when mapping complex text attribution; linear aggregation in flat Euclidean space inevitably forces semantic drift. Looking to connect with researchers in TDA, geometric deep learning, and spectral graph theory. Standard Graph Neural Networks are structurally constrained when mapping complex text attribution: linear aggregation in flat Euclidean space inevitably forces semantic drift. To map high-dimensional knowledge faithfully you have to transition to curved semantic manifolds, where the geometry itself carries the relational structure. Across thirty years of building scientific analysis pipelines — genetics, satellite imagery, multi-continent high-resiliency financial applications — the through-line has been the same: representations must remain mathematically faithful to their underlying geometry, or they stop being interpretable the moment the data leaves your dev set. I've recently open-sourced a framework that discovers emergent knowledge-graph relations in high-order semantic vector spaces through manifold learning and spectral analysis. Initial proofs, a small teaser, and the Python codebase live at [paudley/nonlinear-semantic-graphs](https://github.com/paudley/nonlinear-semantic-graphs); the working paper that motivates the design is in [Publications](#emergent-knowledge-graphs). I'm looking to connect with researchers and applied scientists specialising in **Topological Data Analysis**, **Geometric Deep Learning**, and **Knowledge Representation** — especially anyone working on geodesic aggregation or spectral graph theory — to push these ideas into robust enterprise deployments. [Comment on the LinkedIn original](https://www.linkedin.com/feed/update/urn:li:activity:7458177770238681088/) or [drop me a line directly](#contact). *Standalone: · Canonical anchor: * ---