Semantic data and ontology
Use typed semantic data so Buffaly can connect approximate human requests to concrete objects, remember stable facts, and find the right capability without guessing.
The ontology is the structured map of known objects. Semantic data makes those objects discoverable by meaning, aliases, descriptions, and usage context.
What semantic data is
Semantic data gives Buffaly named entities and relationships it can search and bind to. That lets a request like "the staging site," "the wiki guide," or "the deployment workflow" resolve to known objects instead of staying loose text.
- Use semantic data for durable facts, preferences, environments, tools, services, providers, files, sessions, and accounts.
- Prefer structured memories over long prompt-only notes when the information should be queryable.
- Treat semantic search results as candidates that should be validated before use.
Why binding matters
Users rarely speak in exact prototype names or internal identifiers. Buffaly still needs to bind a request to the right target before acting.
Good binding reduces mistakes such as editing the wrong file, choosing the wrong account, calling a generic tool when a typed action exists, or storing knowledge in the wrong place.
The binding loop
A reliable Buffaly workflow answers two questions before execution. Both matter: a good action with the wrong entity can still produce the wrong result.
What should be used?
Action search finds candidate tools, services, or workflows that can perform the task.
What object is involved?
Entity search finds known files, sessions, environments, services, accounts, providers, or other ontology objects.
Canonical references
When Buffaly resolves an ontology object, it should prefer the canonical reference over a loose label. Think of that reference as the stable name Buffaly uses internally after it understands what you meant.
- Canonical references make tool calls more reliable.
- They make later review easier because the chosen object is explicit.
- They reduce ambiguity when multiple labels, aliases, or descriptions sound similar.
Memory and ontology
Remembered facts and workflows can become part of the semantic layer when they are stored in the right place. The storage choice matters because secrets should never become ordinary searchable documentation or memory.
| What you are storing | Where it belongs |
|---|---|
| Facts, preferences, environments, contacts, and reusable domain knowledge | Normal structured memory or ontology-backed facts |
| Repeatable procedures and operational playbooks | Workflow memory |
| Passwords, API keys, OAuth tokens, bearer tokens, and connection secrets | Secrets storage only |
Reliable binding requests and verification
Good requests name both the intent and the object. Before a high-impact action, ask Buffaly to confirm the binding and the next reversible step.
- Confirm the selected action or tool family.
- Confirm the selected entity or target object.
- Explain whether the target came from semantic search, an exact path, or runtime evidence.
- Call out any remaining ambiguity and the next reversible step.
Maintenance
Semantic data should stay accurate and specific.
When something changes, tell Buffaly what is outdated and what should replace it. Corrections should preserve the reason for the update when that context will help future sessions.
- Store sensitive credentials in secrets, not ontology notes.
- Update or supersede outdated facts instead of leaving conflicting entries.
- Validate important bindings with direct evidence before acting on them.