You can fill a vault for months and still be unable to ask it a simple question: what is active, and what is the next action? The notes are there. Some of them even have frontmatter. And yet when you open a Base in Obsidian 1.15, the view is thin, noisy, or empty. The usual diagnosis is that Bases is unfinished, or that you need a more elaborate plugin stack. More often, the view is telling the truth. It is reading a different place than the one you were writing to.
A Base is only as good as the properties it can see. That is not a slogan. It is a description of how the feature works. Properties in Obsidian live in YAML frontmatter, the block between the --- lines at the top of a note. Bases read those YAML fields. They do not read Dataview-style inline fields such as status:: active written in the body of a note. If the fact you care about exists only as an inline field, the Base will not use it. The table looks broken. The table is accurate.
The Properties Day-1 Kit (for Obsidian) is a short, shared property set, five official Templates-plugin templates that all use the same keys, a starter vault, and a working Base, so you can filter notes by type, status, and next action from the first hour. It is written for Obsidian 1.15.0 and later — public 1.15.0 was released on 2 November 2026 — where Bases is a core plugin. It does not require Templater, Dataview, or any community plugin.
What actually keeps a Base from working?
Five problems show up so regularly that they are worth naming in plain language, because each one has a specific shape and a specific fix.
The first is that properties were never agreed. Notes accumulate. Someone adds Status, someone else adds status, and a third note uses state. A Base then treats those as different columns, or misses half the rows, and the vault looks more organized than it is.
The second is the inline-field habit. If you came to Obsidian through Dataview, status:: active in the body of a note feels natural. Bases do not read that syntax. The kit is not an argument against Dataview. It is a reminder that a Base is a YAML reader, and the fields it is supposed to filter on have to live in the frontmatter.
The third is inconsistent key names, including the older default names that Obsidian itself has moved on from. Current default property names are tags, aliases, and cssclasses. The older names tag, alias, and cssclass were deprecated in Obsidian 1.4, and support for them as default properties was dropped in Obsidian 1.9. Mixing tag and tags is a quiet way to split one idea into two places.
The fourth is dates written as 11/21/2026 instead of 2026-11-21. A date property is a date only when it is written as a date. A slash-delimited string may look fine to you and still fail as a Date value in a view that is trying to sort or filter on due.
The fifth is the one-off property: a field invented for a single note, never used in a view, and never added to a template. A growing list of souvenir fields is how a property set stops being a set. The kit’s rule is simple. Add a property when a view needs a column or a filter you cannot already get, not because one note feels special.
There is a sixth, quieter problem: starting a Base from a blank vault with no rows, no templates, and no written rules for the fields. You can do that work yourself. The kit does it once, in a form you can open in the first hour, so you can see the views working before you file your own work.
Why does a short, shared set beat a private dialect?
Agreed names are an old problem, and the useful answers have always been short, shared, and slightly strict.
When chemists settled on a single symbol per element, a formula written in one laboratory could be read in another. The breakthrough was not better glassware. It was one name, used the same way, for the same thing.
When librarians adopted a shared subject-heading list, a card filed in one catalog could be found by a stranger. The heading did not depend on which cataloger happened to be on duty that afternoon. Consistency made the collection navigable by people who had not built it.
When ISO 8601, first published in 1988, fixed a date as year-month-day, a date stopped being a local dialect. 2026-11-21 means the same thing in every timezone and every office that agrees to write it that way. 11/21/2026 does not. The kit uses that form for a reason: Bases and Obsidian date properties can treat it as a date.
A vault is in the same position. Status and status look to you like one field with casual capitalization. To a Base, they can look like two columns. The Properties Day-1 Kit starts with five lowercase keys and asks you to keep them until a view gives you a reason not to.
What is in the five-field set, and why is it short?
The set is deliberately small: type, status, next, area, and due. The first three are enough to run a useful view. The last two are optional until a view needs them.
type is Text. The values to use are note, project, meeting, source, and decision. It tells a view what kind of thing a note is.
status is Text. The values to use are inbox, active, waiting, done, and parked. It tells a view where the note stands.
next is Text: one concrete next action, or empty. It tells you what to do when you open the view. A list of competing next actions is not a next action. The project template makes that explicit: the next property is the single action you will take, and the body of the note is for context, not for a second, competing action.
area is Text: a short work area, or empty. It is optional grouping. Leave it blank until you need it.
due is Date: YYYY-MM-DD, or empty. Use it only when something actually has a date. An invented due date is worse than none.
A few naming rules sit next to that table, and they are the difference between a set and a pile. Use these exact lowercase keys. One name, one type, across the vault — if status is Text on one note, keep it Text everywhere, because Obsidian assigns a type to a property name vault-wide. Write dates as 2026-11-21. Put wikilinks in quotes when they appear in a property: link: "[[Other note]]". Prefer a short, stable value list for type and status; if you need a new value, add it to Property-set.md first. Do not nest properties; Obsidian properties are a flat YAML map at the top of the note, and official Help notes that nested properties are not a supported editing surface. Do not put Markdown in a text property expecting it to render; official Help states that Markdown is not rendered in text properties.
A note without type, status, and next can still live in the vault. It will not earn its place in the Active or Inbox views until those fields are set. That is intentional. The view stays readable.
What, exactly, is in the kit?
The zip is a 6-page guide, a starter vault, and a README. The guide covers why this set, how Bases read properties, the first-hour path, how to use the set in a vault you already have, and the mistakes the kit is built to prevent.
The starter vault is a folder you open as a vault in Obsidian. Inside it you will find 00-Start-here.md and Property-set.md; five official Templates-plugin templates, all sharing the same keys — note, project, meeting, source, and decision; Bases/Notes.base with Active, Inbox, All notes, and By status views; and a fictional Northshore Studio note set, labeled fictional, so the Base has rows the first time you open it. The example notes include a project, a meeting, a source, a decision, an inbox capture, and a short readme that states the set is fictional. They are not a client record, and they carry no implied results. They exist so you can see the views working.
Notes.base is worth describing in a little more detail, because it is the thing most people want to see first. A global filter includes the Notes folder plus the two kit guides at the vault root, using file.inFolder("Notes") and file.name comparisons from the official Bases syntax. Each view then applies its own status filter. Active is a table of notes whose status is not inbox, done, or parked. Inbox is a table of notes whose status is inbox. All notes is a table with every column in the set. By status is a kanban view grouped on note.status, in the order inbox, active, waiting, done, parked. If a view looks empty, check the YAML on the note — not the body — and check that the status value is one of those five strings, spelled exactly that way.
What does the first hour actually look like?
Open the vault/ folder as a vault in Obsidian 1.15.0 or later — the folder that contains 00-Start-here.md. Enable the core plugins Bases and Templates under Settings, and set the Templates folder to Templates. Open 00-Start-here.md, then open Bases/Notes.base.
Look at the Active view. You should see the fictional recital project and the rate-sheet source. Switch to Inbox: a captured website-copy thought is waiting for a type decision. Switch to By status and walk the kanban. Then create a new note, insert the project template, fill type, status, and next, set status to active, and watch the row appear in the right view. After that, read Property-set.md and keep that set small until you have a reason to add a field.
You can also copy Templates/, Property-set.md, and Bases/Notes.base into a vault you already use. If you copy the Base, adjust or drop the folder filter so it covers the notes you want. Official Help notes that when you insert a template, properties on the template are added to the note, and existing properties are merged. That is why the five templates all share the same keys. Start from a template whenever you can, so the Base keeps receiving notes it can filter.
A daily pass can stay short. Open the Inbox view; for each row, either give it a type and a next action, park it, or delete it. Open the Active view; do the thing in next, then write the new next action — or set status to done or waiting. Leave parked and done notes in the vault. The Active filter already hides them.
When has a sixth field earned a place?
When you are tempted to add a property, write the view you want in a sentence first. “I need to see every active project in the studio area, ordered by due date.” If type, status, area, and due already do that, do not add a field. If they cannot, add one field, give it a type, document it in Property-set.md, and put it on the templates that need it. The guide is a rule for growth, not a prohibition on growth. A short set is the point because a set that is written down, used in templates, and filtered in a view is a system. A long list of unique keys is a diary of exceptions.
How is this different from the Ontology Starter Kit?
The Ontology Starter Kit is a layered Obsidian vault plus a worked ontology in notes, Turtle, and CSV. This kit is a property-and-Bases starter: type, status, next action, and a working view. If you own both, use this one to structure everyday notes, and the ontology kit when you are modelling a domain as a graph. They can sit side by side. Neither replaces the other.
This is an independent tool for people who use Obsidian. It is not an official Obsidian product, and it does not include the Obsidian application. Obsidian is a trademark of its trademark owner.
A vault you can actually query
You are not paying for a lecture about metadata. You are paying for a property set that is already written down, templates that will not drift from that set, a Base that already filters on it, and a short guide that names the exact mistakes that keep a Base from seeing the facts you care about — inline fields, mixed key names, badly formed dates, and one-off properties. The fictional example notes are there so you can see the views working before you file your own work.
Open the folder as a vault, enable two core plugins, and start filing notes the same hour. Get the Properties Day-1 Kit (for Obsidian), walk the Active and Inbox views, and keep the set small until a view gives you a reason to grow it.
The Properties Day-1 Kit is listed on our Tools for Obsidian page, alongside the rest of the tools in that line. You can browse every Organa Obscura tool on the Products page.
Leave a Reply