AridNova Playbook: Terms & Concepts

If this is your first time using AridNova, some terms such as microservices, service dependency graph, Intermediate Representation (IR), and blast radius might be new. And they can come up often. These are concepts that form the foundation of AridNova, but require no prior knowledge to comprehend.

This playbook introduces important terms using simple explanations, labeled figures, and one running example. After grasping these concepts, other parts of the AridNova documentation may become more easier to understand.

1. Introduction & Setup#

Example System#

Throughout this playbook, we'll use a simple online store to explain each concept. This system consists of several microservices, and their responsibilities are the following:

• Customer Service manages customer accounts.
• Order Service processes purchases.
• Payment Service handles payments.
• Product Service keeps track of available products.
• Notification Service sends order confirmation emails.

We will refer to these services throughout the playbook while introducing new concepts.

Example Architecture#

Below is an illustration depicting how the various services in the online store communicate with one another.

Why AridNova Exists#

Modern software systems often consist of many small services that work together. The more complex such systems become, the harder it is to grasp the interaction of services, dependencies, and possible security risks within the system.

AridNova is a tool that helps engineers to perform such tasks by providing an automated analysis of the architecture of the system and relations between its services. Instead of manually tracing dependencies through source code, engineers can see communication between services, possible security risks, and the effect of any changes that are proposed.

Throughout this playbook, we'll use the example system shown in Figure 1 to introduce the concepts that make these analyses possible.

2. Core Architectural Components#

Microservice#

A microservice is a small application that does a single job in an overall software application. In contrast to developing one large application to do all the required jobs, modern systems are divided into several microservices working together for completing the application functionalities. AridNova helps engineers understand how these microservices interact by analyzing their relationships, making it easier to understand system architecture, evaluate changes, and identify potential risks.

In Figure 1, every colored box shows a separate microservice. For example, the Order Service manages the orders placed by customers, the Payment Service manages payments, and the Notification Service sends updates to users. Although every microservice does a separate job, they each communicate with other microservices to perform bigger jobs.

AridNova helps the engineers in analyzing the relationship between these microservices to better understand the overall application architecture and its risks.

Service#

A service is a single application that serves to perform some functions in the microservices architecture. While a microservice is the architectural style for dividing applications into smaller parts, a service is a term used for referring to the individual parts.

For instance, the Order Service, Payment Service, and Notification Service in Figure 1 are examples of services. These services have their unique functions and interact with other services where necessary in order to fulfill requests.

In AridNova, the services are viewed as nodes in the architecture, where engineers can see the relationship between the services and the effects of changing one service to another.

Service Dependency#

A service dependency exists when one service is dependent on the other service for completing their actions. Instead of performing every task itself, a service may request information or functionality from another service.

In Figure 1, the Order Service depends on the Product Service to retrieve product information, the Payment Service to process payments, and the Notification Service to send order confirmations. These relationships are called service dependencies.

Service dependencies provide engineers with knowledge regarding the impact of any change made to the one service on the other. AridNova analyses service dependencies for assessing the risks and impacts of software changes.

Controller#

The role of the controller is to receive requests, coordinate the necessary actions, and send the response. In contrast to implementing all of the application business logic by itself, the controller usually assigns tasks to other pieces of the application.

For instance, a customer making an order will have the request sent first to the controller of the Order Service. It will validate the request, perform the application business logic, and respond back to the client with the results.

Controllers are one of the components identified by AridNova while analyzing a system because they are usually the points of entry to a service.

Entity#

An entity is an object that stores information relevant to a particular service. An entity usually represents a real-world concept like a customer, order, or product. Information relevant to an application is stored in the entity.

In the case of the example system, there could be an Order entity in the Order Service and Product entities in the Product Service. Information related to the customer’s order will be stored in these entities, such as what products were bought and their price and quantity.

AridNova can identify the entities so that the user can have a clearer idea of the architecture of a particular service.

3. System Modeling in AridNova#

Intermediate Representation (IR)#

An Intermediate Representation (IR) is a structured model of a software system that AridNova uses for analysis. Instead of analyzing the source code directly, AridNova converts the software application into an IR in order to capture essential details such as services, controllers, entities and dependencies in the system.

In the case of the example application in Figure 1, the IR would contain the details of the services, their interactions, among other architectural information required in the analysis of the software system. The IR helps in the analysis of the system without relying on the programming language or framework used. It also provides information about the topology, semantics, and business context of the system. Topology is concerned with the connectivity between services, semantics refer to the meaning and behavior of the components, while the business context links the technical architecture with the function of the application. All these details provide AridNova with better insights into the software system.

The creation of an IR involves extracting architectural information from the source code using Conduit. Once the IR is generated, it becomes the basis of various analyses carried out using AridNova.

Topology#

If the Intermediate Representation (IR) gathers all the individual building blocks of your software, the topology is the map showing exactly how those blocks are wired together. Think of it like a city's public transit map: it doesn't tell you why the passengers are traveling, but it clearly displays which stations are connected by which specific train lines. In a software system, topology simply refers to the physical and logical layout of how your services connect and communicate.

Looking at our example online store in Figure 1, the topology is defined by the arrows connecting the colored boxes. This layout shows us that the Order Service has direct communication routes to the Payment, Product, and Notification Services. Just as importantly, it shows us what isn't connected—for instance, it reveals that the Notification Service has no direct route to the Product Service.

Understanding this layout is crucial because you cannot properly secure, test, or update a system if you do not know how its parts are linked. By extracting this topological map directly into the IR, AridNova allows engineers to clearly see the exact pathways data takes. This makes it incredibly easy to spot unexpected connections, broken links, or structural risks at a single glance without having to trace through the source code.

Semantics#

While topology provides the map showing which services are connected, semantics explains what those connections actually mean and how the components behave. If topology is like a city’s road map, semantics is the traffic laws and the type of cargo being transported. It moves beyond just seeing that "Box A talks to Box B" and defines the true intention, role, and logic behind that communication.

In our example online store, topology tells us that the Order Service communicates with the Payment Service. Semantics gives that connection its meaning: it tells us that the Order Service is issuing a specific command—"charge $50 to this credit card"—and expects a success or failure response back. Semantics also defines the roles of individual components inside a service, identifying one piece of code as a "Customer Controller" that handles user logins, and another as an "Order Entity" that stores purchase history.

AridNova uses semantics captured in the Intermediate Representation (IR) so it doesn't just treat your application as a collection of generic boxes and lines. By understanding the actual meaning and behavior behind every service and message, AridNova can perform much smarter analysis—like verifying that sensitive financial actions are only triggered by authorized services, rather than just blindly checking if the services can talk to each other.

Business Context#

If topology is the map of the roads and semantics are the traffic rules, the business context is the actual reason the journey is happening in the first place—like delivering essential groceries to a community. In software, it bridges the gap between the complex technical code and the real-world purpose of the application. It explains why the system exists and what value it is supposed to deliver to the company and its users.

In our online store example, semantics might simply tell us that the Payment Service is updating a database value from "pending" to "approved." The business context, however, understands that a real customer just spent their hard-earned money and expects their order to be fulfilled. If a technical flaw allows a product to be shipped before that payment actually clears, it is not just a simple coding error—it is a critical business failure that directly loses the company money.

By incorporating business context into its analysis, AridNova acts as much more than just a technical debugging tool. It allows automated introspection to search for deep logical conflicts, ensuring that your system's structural design strictly aligns with your real-world business goals—such as keeping customer data private, preventing fraud, and guaranteeing that the online store functions exactly as intended.

Snapshot#

A snapshot refers to a particular state of a microservice system at any given point of time. This means that a snapshot contains the architecture of the system at the point of generating the IR.

As such, AridNova may create a first snapshot prior to changes in the code and then create a second snapshot after implementing the changes. Through the comparison of these snapshots, one may be able to determine what in the system has changed.

Snapshots form the basis of performing analysis like change impact, which is done by comparing the architecture of various versions of a system.

4. Graph & Impact Analysis#

Pipeline#

In AridNova, a pipeline is a sequence of processes that converts a software system into architectural information. Every step in the pipeline executes a particular operation where the output of the previous step is used as the input for the next step.

An example consider creating a pipeline to formal verify a snapshot. It should start with configuring the repositories to analyse, then generate the IR, and finally execute the formal verification logic. You can optionally visualize the results in a more intuitive manner as well.

You can create as many pipelines in AridNova and connect parallel pipelines between allowed processes. Our framework ensures a consistent and repeatable process of analysis of software systems. It is also possible to selectively execute certain analyses without executing others.

Service Dependency Graph#

Service Dependency Graph (SDG) is a visualization that illustrates the interactions between different services in a software system. In the graph, a service is represented as a node while the interaction between two services is represented as a directed edge between the nodes.

It is also possible to construct a call graph using AridNova, which would reveal calls between methods inside a service. Although the Service Dependency Graph reveals the interactions among the services, the call graph offers a detailed insight into request handling inside the service.

Figure 1 is an illustration of a Service Dependency Graph. It shows how the Order Service depends on the Product Service, Payment Service, and Notification Service to complete a customer's request. Such a graph helps engineers easily grasp the interactions between services without going through the source code of the application.

AridNova relies on the Service Dependency Graph as the starting point of most of its analyses. By using this graph, AridNova can determine dependencies, assess impacts of modifications and understand the system's architecture.

Graph Analysis#

Graph analysis is the process of examining the relationships between services to better understand how a software system is connected. While other forms of analysis look at individual services in isolation, graph analysis focuses on how services interact, and how such interaction affects the whole structure of the software system.

With the help of Service Dependency Graph, AridNova can analyze dependencies, discover connected services and assess how any modification made to a service will affect other services. The tool helps developers gain quick insights into complex systems through automated analysis of the code.

Graph analysis is among the fundamental functionalities of AridNova. Through graph analysis, AridNova supports change impact analysis, security analysis, and visualization of dependencies in a software system.

The analysis may sometimes concentrate on certain points within the application known as point cuts. Through focusing on these key points, AridNova is able to conduct analysis on selected points without having to analyze the whole system.

Point Cut#

A point cut is a specific, targeted location within your software's code where a particular action, rule, or analysis is applied. Imagine a city with thousands of roads; if you want to monitor traffic, you don't need to place a camera on every single driveway and quiet side street. Instead, you focus on major intersections and bridges. In software architecture, those critical "intersections"—where important things happen—are your point cuts.

For instance, in our online store, you might want to ensure that only authorized users can process payments. Instead of analyzing every single line of code inside the Payment Service to find security rules, you would define a point cut exactly at the controller where the payment request first enters the service. This pinpoints the exact moment a security check needs to occur.

AridNova relies on point cuts to make its automated analysis incredibly fast and efficient. Rather than wasting time and computing power scanning the entire system top-to-bottom for a specific behavior, AridNova zooms in on these selected key points. By focusing purely on these critical junctions, engineers can quickly run complex checks—like verifying authorization policies or tracing service dependencies—exactly where it matters most.

Change Impact#

Change impact is the process of identifying how a modification to one part of a software system may affect other parts of the application. The relationship between different services has such an impact that even the smallest changes to one service could impact many others.

AridNova compares snapshots of the system to detect changes in services and their dependencies. AridNova then determines how these changes could cascade to other portions of the application.

Determining change impact prior to deploying the software allows the engineers to better assess the risks involved and develop the application further.

Blast Radius#

The blast radius represents the extent of the potential impact of a change on a software system. It refers to the number of services or components that may get affected directly or indirectly upon implementation of a change.

For instance, upon changing the Payment Service in Figure 1, the impact will not be limited to that one service. Since other services are dependent on it, the impact may also affect the process of order fulfillment or notification of the customer. The greater the number of connections between two services, the greater the blast radius.

The blast radius of any change is estimated by AridNova through analyzing relationships from the Service Dependency Graph.

5. Security & Access Control#

Authorization Policy#

An authorization policy defines the rules that determine what actions a user, service, or application can undertake following authentication. Such policies are designed in order to ensure that only the authorized entity accesses particular resources and engages in certain activities.

For example, an authorization policy may allow administrators to manage user accounts while limiting other users to view or edit their respective accounts. The implementation of such authorization policies ensures that sensitive information is protected from any unauthorized access.

AridNova studies authorization policies in order to enable engineers to comprehend how access control has been done in the system.

Role-Based Access Control#

Role-Based Access Control (RBAC) is a method of implementing authorization policies where permissions are assigned to roles, not to users directly. Users are given one or more roles, and their permissions depend on the roles they are assigned.

For instance, an application may define roles such as Administrator, Manager, and Customer. The Administrator will be allowed to manage user accounts, while the Customer role will allow only to view and modify their own orders. Such a technique helps to simplify permission assignments and makes access control easier to implement as the system scales up.

AridNova models RBAC in order to assist engineers in analyzing permission assignment across services.

Principle of Least Privilege#

The Principle of Least Privilege is a foundational security rule stating that any user, program, or service should only be given the bare minimum access needed to do its specific job, and nothing more. Think of a restaurant: a waiter needs access to the dining room and the kitchen to serve food, but they do not need the keys to the manager's safe.

In our online store, the Notification Service needs to know a customer's email address and order status to send a confirmation message. However, it absolutely does not need access to the customer's saved credit card numbers inside the Payment Service. Giving the Notification Service broad, unrestricted access to everything might make development temporarily easier, but it creates a massive security risk—if the Notification Service gets hacked, the attacker suddenly has access to sensitive financial data.

AridNova helps enforce this critical principle by mapping out exactly what permissions every service holds. By analyzing the Service Dependency Graph and checking your system's Authorization Policies, AridNova automatically flags situations where a service or user has been granted unnecessarily broad access. This helps engineers lock down the system and ensures that if one small piece of the application fails, the rest of the system remains secure.

Enforcement Point#

An enforcement point is the location within a software system at which an authorization policy is enforced. It acts to verify that a particular user or service is allowed to perform an operation on a resource.

For instance, when a customer wants to check the order, then the enforcement point verifies if the particular customer has the authorization to do so. In case the request meets the authorization policy, then access is given, otherwise not.

AridNova detects enforcement points in order to help engineers ensure that the authorization policies are properly enforced within a system.

Policy Drift#

Policy drift occurs when the actual implemented security rules in a software system gradually diverge from the originally intended or documented authorization policies. As systems evolve, developers might make ad-hoc changes, rush updates, or add temporary permissions that are never reverted, causing the system's security posture to weaken over time.

For example, a developer might temporarily grant the Notification Service unrestricted access to the Customer Service to resolve an urgent bug. If this elevated access is not removed after the fix, the implemented policy has drifted from the intended secure design.

AridNova detects policy drift by comparing the intended authorization policies against the actual enforcement points extracted into the Intermediate Representation, and even generate test suites to validate them. By continually monitoring these changes across snapshots, engineers can ensure that security rules remain strictly aligned with the organization's requirements as the system grows.

Zero Trust Architecture#

Zero Trust Architecture is a modern security approach based on a simple rule: "never trust, always verify." In older software systems, security was often treated like a castle with a strong moat. Once a user, program, or service got past the front gate, they were trusted to go anywhere and do whatever they wanted. Zero Trust assumes that the moat is never enough, and that threats might already be inside the walls.

In our online store, this means the Payment Service shouldn't blindly trust a request to transfer money just because it comes from the Order Service. Even though both services belong to the same application, the Payment Service must still check the Order Service's "ID" and verify its permissions every single time they communicate. Just because someone made it through the front door of an office building doesn't mean they are allowed to walk into any room and open any locked filing cabinet without swiping their badge again.

AridNova is a vital tool for building and maintaining a Zero Trust Architecture. By mapping out the Service Dependency Graph and pinpointing every single Enforcement Point in the system, AridNova helps engineers guarantee that strict security checks are actively happening between every individual microservice, rather than just relying on a single security checkpoint at the front door.

6. System Risks & Structural Health#

Vulnerability#

A vulnerability is a weakness in a software system that makes the system susceptible to security, reliability, or availability issues. Vulnerabilities are caused by errors in programming, misconfigurations, and defects in design of the system. However, some vulnerabilities can only become apparent when there is a particular event that triggers them. Latent vulnerabilities refer to vulnerabilities that were already present within the software, but which have not been exposed before.

For instance, a service is considered to have a vulnerability if it fails to validate user input and implements access controls improperly. Exploiting these weaknesses would make it possible to have unauthorized access to the system or cause any undesired actions.

AridNova assists engineers in discovering and analyzing vulnerabilities in the light of the architecture of the software system. This makes it easy to comprehend the possible impact of any security problems.

Latent Vulnerability#

While a standard vulnerability is an active weakness that can be exploited right now, a latent vulnerability is a hidden flaw that is already built into the system but remains dormant. Think of it like a weakened beam hidden behind a wall; it poses no immediate danger under normal conditions, but it will crack if a heavy new floor is added above it. These flaws are currently unexploitable but are waiting for a specific event, configuration tweak, or future code change to suddenly trigger them.

For example, imagine the Notification Service has a missing security check that allows it to send thousands of emails at once. However, because the Order Service currently restricts customers to making only one purchase per minute, this flaw can never actually be reached or exploited. The vulnerability is "latent." If a developer later updates the Order Service to process massive bulk orders instantly, that hidden weakness in the Notification Service is suddenly exposed, potentially allowing an attacker to spam users.

AridNova is designed to hunt down these dormant risks. By deeply analyzing the relationships between services and using tools, including automated introspection (Aegis) and change impact analysis, AridNova helps engineers uncover these hidden traps before a routine update or seemingly harmless system change accidentally turns a latent vulnerability into an active threat.

Attack Surface#

The attack surface is the complete set of points from which an attacker can interact with the software system. It consists of services, APIs, endpoints, and other pieces of software that are available for use by users or other software.

For the sample application, all services that communicate with other services or receive external requests become parts of the attack surface of the system. With the growth of the system and increase in the number of services, the attack surface usually expands.

AridNova assists in understanding the attack surface of the system through analyzing the connectivity between services and finding out which pieces of software can be exposed.

Anti-pattern#

An anti-pattern is essentially a "lesson learned the hard way"—a common approach to building software that might seem like a quick fix or a good idea initially, but ultimately causes more problems than it solves. In a microservices system, anti-patterns are structural bad habits that make the application increasingly difficult to manage, expand, or secure as it grows.

For example, imagine if the Order Service, Payment Service, and Notification Service all bypassed the Customer Service to directly read and write to the exact same database. While a developer might do this to temporarily speed up a process, it creates a fragile, tangled mess. If the customer database ever needs to be updated or secured differently, every single one of those services might break. Another common anti-pattern is a "God Service," where one service (like the Order Service) slowly starts taking over the jobs of others, defeating the purpose of having small, separate microservices in the first place.

AridNova acts as an architectural supervisor, automatically scanning your system's Intermediate Representation and Service Dependency Graph to detect these anti-patterns. By visually flagging tangled dependencies, overly complex communication loops, or structural bad habits early, AridNova helps engineers clean up their architecture before it becomes a nightmare to maintain or protect.

Technical Debt#

If anti-patterns are the bad structural habits of software design, technical debt is the long-term price you pay for keeping them. Just like taking out a financial loan to build something quickly, technical debt occurs when developers take quick shortcuts—like implementing an anti-pattern to meet a tight deadline—rather than building a clean, sustainable solution. You gain speed today, but over time, those accumulated shortcuts accrue "interest" that makes the entire system increasingly fragile, complex, and expensive to maintain or update.

For instance, imagine the online store team needs to launch a flash sale by Friday. To save time, a developer uses an anti-pattern by hardcoding a temporary discount rule directly inside the Order Service instead of integrating it properly through the Product Service. While the store launches on time, that shortcut is now technical debt. Months later, when another engineer tries to update product pricing, that forgotten, hardcoded rule causes mysterious errors and unexpected bugs.

AridNova helps teams keep technical debt from quietly spiraling out of control. By tracking snapshots over time and running graph analysis across your system, AridNova makes hidden technical debt visible. It automatically highlights accumulating shortcuts—such as active anti-patterns, policy drift, or tangled service dependencies—allowing engineers to prioritize and pay off technical debt before it leads to system outages or security breaches.

7. Advanced Validation & Automation#

Formal Verification#

Formal verification is a mathematical process of verifying the satisfaction of a software system to a particular set of specified rules or security requirements. Unlike traditional testing, formal verification gives greater assurance as far as security of a system is concerned since properties are verified for every possible run included in the model.

In AridNova, formal verification is employed to verify authorization policies and access control. By looking at the model of the system, AridNova helps to detect any policy violation, access permission conflicts or access paths that would not have been discovered otherwise.

Introspection#

Introspection is like having a smart inspector that constantly reviews a house's blueprints while it is being built. Instead of waiting until construction is completely finished to discover that a front door was installed without a lock, this process allows software to proactively examine its own internal design. It automatically flags potential weaknesses or missing safety features as the system is actively being created.

In AridNova, introspection goes beyond acting as a simple spell-checker for common coding mistakes. It compares the technical code—captured in the Intermediate Representation—against your actual real-world goals, such as ensuring the Payment Service keeps customer data private. If a service's design fundamentally contradicts what it is supposed to do, AridNova immediately spots the problem rather than just making blind guesses.

By combining this deep understanding with continuous self-checking, developers can catch incredibly complex security risks very early in the development process. It highlights deep logical conflicts or missing safety steps before the application ever reaches the public. Ultimately, this self-aware approach ensures that the various services communicating in your system remain secure and structurally sound from day one.

Continuous Integration / Continuous Deployment (CI/CD)#

Imagine a highly efficient car factory assembly line. Instead of building the entire car over several months and waiting until the very end to see if the engine starts, workers add small pieces one by one. Every time a new piece is added, an automated machine immediately tests it to ensure it fits perfectly (Continuous Integration). If it passes the test, the car automatically moves down the line to be shipped to the dealership (Continuous Deployment). In software, CI/CD is this automated "assembly line." It is a system that allows developers to constantly test, merge, and release small new code updates safely and quickly.

In our online store, if a developer writes a new feature for the Order Service, they do not manually shut down the website to install it. Instead, they submit their new code to the CI/CD pipeline. The pipeline automatically builds the code, runs a battery of tests to ensure the shopping cart still works, and—if everything passes—smoothly deploys the update to the live website without interrupting the customers.

AridNova plugs directly into this automated assembly line. Every time a developer submits new code, the CI/CD pipeline can trigger AridNova to instantly create a new system snapshot (yet to be made publically available), map the updated topology, and run its deep introspection checks. By sitting directly on the assembly line, AridNova ensures that hidden vulnerabilities, policy drifts, or architectural anti-patterns are automatically caught and blocked before the faulty code ever reaches your real-world customers.

8. Bringing It All Together#

The combination of the concepts described in this playbook forms AridNova's unified pipeline for software comprehension, security, and analysis. Rather than forcing engineers to manually inspect thousands of lines of source code across multiple repositories, AridNova constructs a structured, highly intelligent model of your entire software system and performs deep analysis directly on that model.

A typical workflow begins with the Conduit tool, which translates your raw application source code into the Intermediate Representation (IR). This IR captures all the essential building blocks—services, controllers, entities, and enforcement points. Using this data, AridNova generates a comprehensive Service Dependency Graph that maps out exactly how your system communicates.

With this foundation in place, AridNova unlocks a vast suite of capabilities. Beyond basic dependency visualization and graph analysis, it allows teams to comprehensively map their total attack surface and accurately predict the blast radius of any proposed code changes by comparing system snapshots. It continuously monitors for policy drift, rigorously tests RBAC rules through formal verification, and uses automated introspection to catch deep architectural vulnerabilities and logical conflicts before they ever reach production.

What makes AridNova truly powerful is how these individual processes can be connected "criss-cross" to perform highly complex, comprehensive analyses. You can link different pipelines together to automate advanced workflows. For example, by linking formal verification with the automated test scenario generator, AridNova can automatically produce validation tests to catch policy drift. Similarly, by feeding two different system snapshots into the test generator, it can instantly create regression tests to ensure new updates haven't broken existing features.

By weaving all of these moving parts together, AridNova provides engineers with a holistic view of both system architecture and security posture—delivering proactive insights and automated validation that would be nearly impossible to achieve through manual code review alone.

Understanding the concepts outlined in this playbook provides the perfect foundation. You are now ready to explore the rest of the AridNova documentation and start analyzing your own systems with confidence.