Your team's knowledge doesn't fit seven boxes

Every company-knowledge tool ships a fixed schema. Pulse’s is decisions, people, topics, features, customers, skills, and documents, seven shapes that cover a lot of a software team’s work. But not all of it. The thing your team actually tracks, a vendor, an incident, an experiment, a candidate, a regulated control, rarely fits one of the seven, so it gets flattened into a note and loses the one property that made it useful: structure.

A note is where a fact goes to stop being queryable. “Vendor Northwind, contract renews 2026-08-01, owner Priya, $42k/yr” is four fields pretending to be a sentence. Once it’s prose, you can’t ask “which vendors renew this quarter” or “what do we spend per vendor,” because the shape that would answer those never existed. The fix isn’t a better note. It’s letting you add the box.

Model your domain, not ours

Custom entity types let a team define its own kinds. You name the kind, Vendor, Incident, Experiment, give it the fields that matter, contract date, severity, hypothesis, and from then on it behaves like a built-in. Records get a compiled-truth page, show up in Map next to the decisions and people they relate to, and answer questions in Ask. The seven kinds stop being a ceiling and become a starting point.

Each type can also carry an extraction prompt. Give “Incident” one and Pulse pulls incidents out of the documents it already ingests, so the structure fills itself in from the work instead of waiting on someone to type it. Leave it off and records stay hand-entered. Either way the kind is real, not a tag bolted onto a note.

Two tiers: the team’s, and yours

Not every kind belongs to the whole company. So there are two scopes. Workspace types are defined by an admin and shared, anyone can add records, and they appear in Map and search for the team, the right home for Vendor or Incident. Personal typesare defined by any member and private to them, a reading list, a list of people to follow up with, a personal experiment log, that never appear on a teammate’s Map, in their search, or on any team surface.

Personal types ride the same privacy spine as personal memory: owner-only by construction, absent from every aggregate, snapshot, and briefing. A personal entity’s searchable text is written so only its owner can retrieve it; it is structurally incapable of surfacing for anyone else. You get to model your own work without quietly publishing it to the team.

The constraints that came first

• Personal stays personal.A personal type and its records never widen anyone’s view. Map, Ask, the MCP tools, and auto-extraction all operate on workspace-scoped types only; a personal entity is invisible to every surface but its owner’s.
• Admins shape the team’s schema, members fill it. Defining a workspace kind is an owner/admin job, the same standing as the glossary or topics. Adding records is open to any member. A member can always define their own personal kinds.
• A type’s scope is fixed once set.A kind can’t silently flip from personal to workspace and expose every record; scope is decided at creation. Deleting a type is a soft delete that keeps existing records for audit.

Why this matters more as agents read your data

A human reading a note skims past the missing structure. An agent can’t act on what isn’t modeled, it can only use the shapes you gave it. The same argument we made about a process graph over a document graph applies here: structure is what makes knowledge usable by software, not just searchable by people. Custom types are how you extend that structure to the parts of your domain we didn’t anticipate.

We picked seven kinds because they cover most of what software teams decide and ship. We were never going to guess the eighth that matters to you. So now you add it. Live walkthrough at pulsehq.tech.