Introduction of Angelusarity Framework: Conversational Ontological Discovery and Three-Universe Architecture

[angelherdez1979]

Dear Ontolog Community,

I am Angel Hernández Rivera, an independent researcher. I am glad to join this forum and would like to share the core thesis of Angelusarity, a framework focused on how structured conversation can be used to discover, refine, and organize conceptual knowledge into coherent ontological structures.

The framework proposes an alternative to traditional, siloed software architectures by anchoring organization logic into three decoupled ontological layers:

1. Existential Universe (Ontology): Houses immutable "Singularities" and their transient states ("Accidents"), creating a single source of truth that prevents data duplication.

2. Transformation Universe (Phenomenology): Restricts data mutation exclusively to explicit, vector-driven "Events".

3. Governance Universe (Tutelarity): Employs logical "Guardians" that intercept and validate events against mathematical and systemic constraints before execution.

I have summarized the philosophical foundations and structural rules in our working paper: "Angelusarity — Descubrimiento Ontológico Conversacional" (available at Angelusarity — Descubrimiento Ontológico Conversacional

[angelherdez1979]

Quick follow-up and apology: the whitepaper link I shared was originally only rendering in Spanish. The English version is now live at the same URL (https://angelusarity.com/), with a language toggle if you'd prefer to read the Spanish original.

Apologies for the inconvenience and thank you to anyone who took the time to look at it despite the language barrier. I'd still very much welcome any critique, references, or counterexamples.

[Pilar Ramírez Amurrio]

hello:

Shared on LinkedIn, the comments: respectable, but I lack something in the didactic approach of the proposed model. 

For me the porposal introduces the figure of the creator as descriptor, so this figure doesn´t create anything, maybe the correct name would be descriptor who is, in fact the one who needs the app or the future owner, beacause the description of the needs is, generally, the first that is in the customer hands to agree with programers.

Thanks

[angelherdez1979]

"Thank you for this insightful feedback! You’ve touched on a very critical distinction regarding roles.

While 'Descriptor' aligns well with traditional, passive requirement-gathering, in this model I see this role more as a Constructor (Builder).

They aren't just listing needs on a paper; they are actively architecting the structural constraints, logical rules, and the foundational scaffolding of the system. The programmer then implements the concrete code within that pre-built framework.

However, I completely agree on the didactic aspect. The model is quite abstract right now, and introducing concrete use cases is the logical next step to make these boundaries clear. I look forward to sharing more of these foundations soon!"

Thanks, again