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.
]]>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:
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.
]]>In my project, coding-ethos, we focus heavily on building policy-as-code guardrails for AI agents — using CEL policies, Git hooks, sandboxing, and MCP 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:
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.
]]>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 MCP server the agent can query at runtime.
The key invariant: the engine that writes the markdown rules is the exact same engine that evaluates CEL 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 if you want the implementation walk-through, and feature requests are welcome on the repo.
]]>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; the working paper that motivates the design is in Publications.
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 or drop me a line directly.
]]>