Frequently Asked Questions
Garnet Framework is an open-source framework for building living digital twins of operations and context-aware solutions through dynamic knowledge graphs and the ETSI NGSI-LD open standard.
A living digital twin is a connected operational model that continuously reflects the entities involved, their properties and relationships, what is happening now, what changed over time, and where it is happening. Applications, analytics, digital twins, and AI systems can use that same live, traceable context.
Garnet Framework connects operational data into a living digital twin represented as a dynamic knowledge graph. The NGSI-LD foundation remains consistent across domains, while each solution defines its own domain model and application behavior. Consumers can query current, relational, temporal, and spatial context, subscribe to relevant changes, and analyze history from the data lake.
What is Garnet Framework?
Garnet Framework creates and manages a living digital twin of operations. Its dynamic knowledge graph can represent people, organizations, assets, events, processes, locations, observations, business records, and any other identifiable domain concept, together with their relationships and metadata.
The model evolves as operations change. It preserves current state, observation time, historical changes, spatial context, and metadata about both properties and relationships. Applications, analytics, digital twins, and AI systems can read or subscribe to the same operational context instead of reconstructing it independently.
At its core is a customized Scorpio NGSI-LD Context Broker. Garnet Framework adds deployable AWS infrastructure, API access, Amazon SQS ingestion, subscriptions, temporal and geospatial context management, AWS IoT synchronization, monitoring, and an Amazon S3 data lake. Producers and consumers use the living operational model through the ETSI NGSI-LD standard.
What remains consistent across domains, and what does each solution define?
Garnet Framework separates a reusable context foundation from the domain and application layers built on it.
| Layer | What it defines |
|---|---|
| NGSI-LD foundation | Entities, properties, relationships, attribute metadata, identifiers, temporal and geospatial representations, queries, and subscriptions |
| Garnet Framework | The deployable context broker, ingestion paths, live and temporal context handling, subscriptions, monitoring, AWS integrations, and historical data lake |
| Domain and application layer | Entity types, attributes, relationships, vocabulary, validation, ownership, permissions, workflows, interfaces, and business behavior for a specific solution |
The foundation stays the same whether the solution models an airline journey, an upstream production system, a customer account, a factory, or a supply network. The domain and application layer defines what concepts such as Traveler, Booking, Well, Flowline, Contract, or WorkOrder mean and how the solution uses them.
Which domains and use cases can use Garnet Framework?
Garnet Framework and NGSI-LD are designed to be domain-independent. Any domain can use the same foundation when applications need a connected and changing view of people, assets, events, places, processes, business records, and their context.
Examples include:
| Domain | Example connected context | Example outcomes |
|---|---|---|
| Airlines and travel | Travelers, loyalty memberships, bookings, flights, aircraft, disruptions, baggage, and service calls | Journey recovery, informed customer service, disruption management, and operational coordination |
| Energy and upstream oil and gas | Wells, flowlines, separators, sensors, production events, organizations, and work orders | Production monitoring, asset context, anomaly investigation, and maintenance coordination |
| Customer and commercial operations | Accounts, contacts, contracts, products, usage, interactions, cases, and account teams | Context-aware service, renewal preparation, customer health, and next-best actions |
| Manufacturing and industrial operations | Equipment, lines, materials, observations, quality events, operators, and maintenance activities | Operational monitoring, traceable quality, downtime analysis, and maintenance decisions |
| Supply chain and logistics | Orders, shipments, inventory, vehicles, facilities, routes, conditions, and exceptions | End-to-end visibility, exception management, provenance, and coordinated response |
| Buildings, utilities, and cities | Spaces, equipment, occupants, meters, networks, incidents, weather, and service teams | Energy optimization, facilities operations, service reliability, and coordinated response |
| Financial and insurance operations | Customers, accounts, transactions, policies, claims, controls, alerts, and investigations | Connected case context, explainable controls, investigation support, and operational risk management |
The framework remains the same across these examples. The solution team defines the domain model, integrations, policies, user experience, and application logic required for its use case.
What is a context layer, and when is it useful?
In this documentation, context layer describes the architectural role of the living digital twin. It is the shared, continuously updated operational model between systems that produce context and the applications, analytics, digital twins, or AI systems that consume it.
The context layer becomes valuable whenever the data needed to understand a situation is fragmented or missing explicit context. That can happen across several systems or inside one system whose records are not connected, whose history is difficult to query, or whose spatial information is modeled separately.
Without one, each application must learn the schemas, identifiers, ownership rules, and integration details of every source it uses. Relationships are repeatedly rebuilt in application code, and each new consumer creates another set of joins and mappings.
Garnet Framework provides a common operational model:
- Source systems publish relevant facts using stable entity identities.
- Relationships between assets, events, locations, people, and business records become data.
- Consumers query current context without integrating separately with every producer.
- Subscriptions notify consumers when relevant context changes.
- Temporal and geospatial context use a consistent representation and API.
Its value grows when relationships, temporal history, spatial context, metadata, or changing state need to be used consistently by several applications, teams, analytics workloads, digital twins, or agents.
How does Garnet Framework fit with existing systems?
Existing systems can remain authoritative for the records and processes they own. Garnet Framework connects the relevant context through stable identities, explicit relationships, and the NGSI-LD contract.
It can become the shared context-serving and change-notification layer, replacing duplicated components such as:
- Point-to-point read integrations repeated by each application
- Bespoke APIs that join the same source systems in slightly different ways
- Application-specific copies of asset and relationship models
- Polling services used to detect context changes or threshold conditions
- A homegrown current-state service that has no shared information model
- A graph-backed operational API when its main job is standard context retrieval rather than graph-native analysis
Specialized systems continue to handle the workloads they are designed for:
- CRM, ERP, EAM, airline reservation, historian, GIS, IoT, and other operational platforms remain systems of record
- Data warehouses and analytical platforms handle large analytical workloads
- Specialized graph engines handle graph algorithms and graph-native queries
- Vector stores and document search systems handle unstructured semantic retrieval
- The solution layer owns domain governance, validation, security, workflows, and operational responsibility
The result is a connected operational model that complements those systems while reducing repeated integration and context reconstruction.
How does data move through Garnet Framework?
Any source can contribute context through an integration that maps its relevant data to the solution's NGSI-LD domain model. Available interfaces include the NGSI-LD API, the managed Amazon SQS ingestion path, and purpose-built integrations such as AWS IoT synchronization.
Consumers can:
- Query entities, properties, relationships, time, and location
- Subscribe to relevant changes instead of polling
- Process notifications through application or event-driven workflows
- Analyze historical context delivered to Amazon S3
External applications, analytics, AI agents, and specialized graph workloads can also publish derived insights back as NGSI-LD context. Other authorized consumers can then query those results, subscribe to changes, or analyze them from the data lake.
How do knowledge graphs, graph databases, and Garnet Framework fit together?
These terms describe different layers:
| Term | What it describes |
|---|---|
| Knowledge graph | A connected information model made of identifiable things, their properties, and their relationships |
| Graph database | A storage and query engine optimized for graph-native access patterns |
| Garnet Framework | A context-management framework that maintains and exposes a dynamic knowledge graph through the NGSI-LD contract |
Garnet Framework is therefore not separate from the knowledge graph. The dynamic knowledge graph is the operational model it creates and manages. Its current packaged persistence uses PostgreSQL-compatible storage rather than requiring a native graph database.
Garnet Framework may replace a graph-backed serving layer when the main requirement is to exchange current context across producers and consumers using standard entities, relationships, temporal metadata, geospatial queries, and condition-based subscriptions.
Use both in parallel when you also need deep path exploration, graph algorithms, graph-native query languages, specialized reasoning, or large-scale graph retrieval. A common architecture is:
- Garnet Framework remains the shared operational context authority.
- A subscription or event pipeline sends the required subset to a specialized graph engine.
- The graph workload analyzes or enriches that subset.
- Useful results are published back to Garnet Framework with their source, time, and relationships.
- Other applications and agents query or subscribe to the enriched context.
A graph database can store many of the same facts, but it does not by itself provide the complete NGSI-LD context-management contract. Producer update semantics, standardized representations, attribute-level temporal context, geospatial context, and conditional subscriptions otherwise need to be designed and operated as additional application infrastructure.
How is Garnet Framework different from a data lake?
A data lake is optimized for durable storage and analytical processing across large historical datasets. It is generally not the interface an operational application uses to retrieve the current state of an entity or subscribe to a changing condition.
Garnet Framework provides the operational context API and automatically delivers context changes into Amazon S3. Teams can use the live layer for current decisions and subscriptions, then use Amazon Athena or other analytical tools for longer-window analysis.
The two capabilities are complementary and share the same structured context.
How does Garnet Framework support AI systems?
Garnet Framework provides structured operational facts rather than generated answers. An AI system can retrieve stable identities, explicit relationships, current values, timestamps, locations, and source metadata before making a recommendation or taking an action.
This grounds context-aware agents in the same living operational model used by applications, analytics, and digital twins. Agents can use general entity, query, relationship, temporal, and geospatial operations rather than relying on a separate domain-specific integration for every type of operational object.
External AI services can classify, predict, recommend, or reason over that context, then publish derived insights back to Garnet Framework with their source, timestamp, confidence, and relationships. Other consumers can query or subscribe to the enriched result. Vector stores can continue to provide unstructured retrieval, while specialized graph engines can provide graph-native analysis.
How does NGSI-LD support different domain models?
NGSI-LD defines the common information foundation and API contract: entities, properties, relationships, identifiers, attribute metadata, temporal information, geospatial representation, querying, and subscriptions.
The domain and application layer defines the actual model used by a solution. This includes entity types, attributes, relationships, vocabulary, identifiers, validation rules, ownership, access policies, and model versioning.
For example, NGSI-LD defines how a Relationship and its metadata are represented. An airline solution defines what operatedBy, bookedBy, or affectedBy mean. An upstream energy solution defines feeds, connectedTo, or maintainedBy. Both use the same underlying representation, query patterns, and subscription mechanisms.
What does using an open standard provide?
NGSI-LD gives producers and consumers a documented, domain-independent contract. It standardizes core representations, operations, queries, subscriptions, temporal and geospatial patterns, and semantic identifiers while allowing each solution to define its domain model.
This improves interoperability and makes implementation replacement more realistic, but migration is not automatic. Test the features, extensions, performance, authentication, and operational behavior your workload depends on.
How is Garnet Framework deployed?
Garnet Framework is deployed into your AWS account through AWS CDK. The packaged architecture includes concentrated and distributed context-broker options, API and load-balancing infrastructure, PostgreSQL-compatible persistence, messaging, ingestion, monitoring, AWS IoT integration, and the historical data lake.
See the architecture overview and deployment guide for the current components and configuration options.
How should teams evaluate Garnet Framework for production?
Garnet Framework is a deployable open-source foundation that runs in your AWS account. Teams control the architecture, security, domain model, integrations, and operating model around their deployment.
The concentrated architecture is intended for development, testing, and focused evaluations. The distributed architecture is the appropriate starting point for scalability and resilience testing. Selecting an architecture is only the beginning of that evaluation.
Before production, teams should design and validate:
- Strong authentication and authorization beyond the default development token
- Network boundaries, tenant isolation, and data access policies
- Availability, backup, recovery, reconciliation, and deletion behavior
- Monitoring, alerting, operational runbooks, and support ownership
- Expected update volume, query patterns, notification fan-out, and latency
- Load, failure, recovery, and cost tests using realistic traffic
- Domain-model governance, identifiers, validation, and versioning
This is the same due diligence expected for any self-managed operational data platform. Garnet Framework provides the foundation, while each team validates the complete workload against its own production requirements.
What is a good first evaluation?
Start with one valuable operational question that is difficult today because the required relationships, metadata, history, time, or location are not available together. The data may come from one fragmented source or several systems.
Model only the identities, properties, and relationships needed to answer that question. Connect one or two producers, build one consumer or agent, and measure whether the shared context reduces integration work or improves decision speed. Expand the model from evidence rather than attempting an enterprise-wide ontology first.
Is Garnet Framework open source?
Yes. Garnet Framework is available in the awslabs/garnet-framework repository under the MIT No Attribution license.