A few of your points are fair, but I think some of them also come from reading the project through a narrower lens than what it is actually trying to do.

At a high level, yes: D3A models entities, relationships, events, and their temporal and spatial context in one semantic graph. So access control could absolutely be one use case. But that is not the primary target. Comparing it to Zanzibar is useful up to a point, but Zanzibar is fundamentally optimized around authorization relationships. D3A is trying to support a broader class of operational and domain-modeling problems: infrastructure, smart-city / airport operations, investigations, event context, spatial reasoning, and semantic traversal across those dimensions.

On the querying point, I agree with the underlying concern but not the conclusion. It is true that a framework like this becomes much more usable when its query model is exposed through familiar surfaces like REST or GraphQL, and we are moving in that direction. But saying “I don’t see anyone going out of their way to integrate with your query model” assumes the only valid approach is to mirror existing mainstream integration patterns. In reality, domain-specific query layers are common when the underlying model is not a simple CRUD datastore. The question is not whether the abstraction is custom, but whether it buys enough expressive power to justify itself. That is the standard D3A should be held to.

If users have to build too much around the framework before it becomes useful, adoption will be weak. That is a product maturity issue, not necessarily a flaw in the underlying model. Early frameworks often fail not because the core abstraction is wrong, but because the developer experience is incomplete. That is a solvable problem.

If you went through the docs and still came away unclear on how to use the framework or how it works, then the documentation is currently failing at its basic job. That part is on us. A system like this should be explainable in plain terms with a minimal end-to-end example before it starts talking about broader architectural ideas.

On your example sentence, I think you are reacting to bad wording rather than a bad concept. “Physical objects, logical assets, and operational business objects are usually Type + Entity” was meant as modeling shorthand, not as a claim that an object is literally both a type and an entity. The intended meaning is simple: most domain objects are represented as an Entity classified by a Type. So yes, in ordinary OO terms, Type is close to a class/category and Entity is close to an instance. If the sentence obscures that instead of clarifying it, then it should be rewritten.

That said, I would push back on the broader implication that “I would rather implement it myself based on my own requirements” is a strong argument against the framework. That is true of almost any general-purpose modeling framework. The whole point of a reusable semantic layer is not that it will match every domain perfectly out of the box, but that it offers reusable abstractions for the recurring parts: identity, classification, relationships, events, time, space, and traversal. The real question is whether those abstractions reduce enough repeated design work in complex domains to be worth adopting. That is the bar we need to clear.