Updated adr to make it more atomic. Implemented ADR specialist aI agent

Author: aleCombi

dev_tools/adr_agent.py

@@ -0,0 +1,77 @@
+import os
+import yaml
+from typing import List, Dict
+from langchain_community.vectorstores import Chroma
+from langchain_ollama import OllamaEmbeddings, ChatOllama
+from langchain.chains import RetrievalQA
+from langchain.schema import Document
+
+class ADRAgent:
+    def __init__(self, adr_directory: str, model_name: str = "mistral"):
+        """
+        Initializes the ADR Agent by loading all ADR files from the given directory.
+        """
+        self.adr_directory = adr_directory
+        self.model_name = model_name
+        self.adr_vectorstore = self.index_adrs()
+        self.llm_retrieval = ChatOllama(model=self.model_name)  # AI model for processing ADRs
+        self.design_qa = RetrievalQA.from_chain_type(self.llm_retrieval, retriever=self.adr_vectorstore.as_retriever())
+    
+    def load_adrs(self) -> List[Document]:
+        """
+        Loads all ADRs from the specified directory, parses them, and converts them into Documents.
+        """
+        documents = []
+        for file in os.listdir(self.adr_directory):
+            if file.endswith(".yaml") and file.startswith("adr-"):
+                file_path = os.path.join(self.adr_directory, file)
+                with open(file_path, "r", encoding="utf-8") as f:
+                    adr_data = yaml.safe_load(f)
+                
+                adr_text = f"{adr_data['title']}\n\n{adr_data['context']}\n\n{adr_data['decision']}"
+                metadata = {
+                    "adr_id": adr_data["adr_id"],
+                    "title": adr_data["title"],
+                    "filename": file_path
+                }
+                documents.append(Document(page_content=adr_text, metadata=metadata))
+        return documents
+    
+    def index_adrs(self):
+        """
+        Indexes ADRs in ChromaDB for semantic search.
+        """
+        adr_documents = self.load_adrs()
+        embedding_model = OllamaEmbeddings(model=self.model_name)  # Use specified embedding model
+        return Chroma.from_documents(adr_documents, embedding=embedding_model)
+    
+    def retrieve_relevant_adrs(self, feature_request: str, k=3) -> List[Document]:
+        """
+        Fetches the most relevant ADRs using vector similarity search.
+        """
+        retriever = self.adr_vectorstore.as_retriever(search_kwargs={"k": k})
+        results = retriever.invoke(feature_request)
+        return results["documents"]
+    
+    def generate_high_level_steps(self, feature_request: str) -> List[str]:
+        """
+        Uses AI-powered RetrievalQA to generate structured high-level implementation steps.
+        """
+        prompt = f"""
+        You are an AI agent helping a developer implement a feature request in Hedgehog2.jl, a Julia derivatives pricing library.
+        Your task is to retrieve relevant design decisions (ADRs) and provide structured implementation steps.
+
+        Feature Request: {feature_request}
+        
+        Respond with clear, step-by-step guidance based on existing design decisions.
+        """
+        response = self.design_qa.invoke(prompt)
+        return response["result"]
+
+# Main execution
+if __name__ == "__main__":
+    adr_agent = ADRAgent("./docs/adr", model_name="mistral")  # Replace with your ADR directory path and preferred model
+    feature_request = "Implement put options pricing using Black-Scholes analytical formulas"
+    steps = adr_agent.generate_high_level_steps(feature_request)
+    
+    print(steps)

docs/adr/adr-001-payoff.yaml

@@ -0,0 +1,26 @@
+adr_id: 001
+title: "Payoff Object Design"
+status: Accepted
+date: 2025-03-11
+context: |
+  The pricing framework must support multiple payoffs while maintaining type safety and modularity.
+  A `payoff` should represent the contract terms and intrinsic valuation function independently of market inputs or pricing models.
+
+decision: |
+  - Define a `payoff` type that subtypes `AbstractPayoff`.
+  - Each payoff should encapsulate contract details (e.g., strike, expiry) and provide an intrinsic value function.
+  - Payoff objects should not contain market assumptions or pricing logic.
+
+consequences:
+  positive:
+    - "Encapsulates contract-specific logic separately from pricing and market assumptions."
+    - "Allows defining new payoffs without modifying existing pricing structures."
+  negative:
+    - "Requires defining explicit struct types for each new payoff format."
+
+alternatives:
+  - name: "Store pricing logic inside the `AbstractPayoff` subtypes"
+    pros: "Simplifies structure since each payoff knows how to price itself."
+    cons: "Reduces flexibility—pricing depends on the payoff rather than being modular."
+
+references:

docs/adr/adr-001-structuring-pricing.yaml

@@ -0,0 +1,26 @@
+adr_id: 002
+title: "Market Inputs Structure"
+status: Accepted
+date: 2025-03-11
+context: |
+  Market data, such as volatility surfaces and discount curves, must be structured separately from pricing methods.
+  `marketInputs` should represent external market conditions relevant for pricing.
+
+decision: |
+  - Define a `marketInputs` type that subtypes `AbstractMarketInputs`.
+  - This struct should contain market parameters (e.g., spot price, volatility, interest rate) but not pricing logic.
+  - Market inputs should be designed for easy extension to support additional factors.
+
+consequences:
+  positive:
+    - "Keeps market data independent of pricing models, allowing flexible combinations."
+    - "New market models can be added without modifying existing pricing methods."
+  negative:
+    - "Requires explicitly defining each market input struct."
+
+alternatives:
+  - name: "Pass market data as separate function arguments"
+    pros: "Avoids struct overhead and keeps the API simple."
+    cons: "Less structured and harder to extend for new market conditions."
+
+references:

docs/adr/adr-002-market-inputs.yaml

@@ -0,0 +1,25 @@
+adr_id: 003
+title: "Pricing Method Structure"
+status: Accepted
+date: 2025-03-11
+context: |
+  Pricing models require specific numerical techniques and assumptions. To maintain modularity, these methods should be encapsulated in separate objects.
+
+decision: |
+  - Define a `pricingMethod` type that subtypes `AbstractPricingMethod`.
+  - This struct should contain configuration details for the pricing technique (e.g., finite difference grid size, Monte Carlo paths) but should not include the pricing algorithm itself.
+  - Pricing functions should be implemented separately and dispatched based on `(payoff, marketInputs, pricingMethod)`.
+
+consequences:
+  positive:
+    - "Allows pricing techniques to be swapped independently of payoffs and market inputs."
+    - "Enables efficient method specialization using Julia's multiple dispatch."
+  negative:
+    - "Requires defining a struct for each pricing method instead of using a simple function call."
+
+alternatives:
+  - name: "Embed pricing logic inside market inputs or payoffs"
+    pros: "Removes the need for separate pricing method objects."
+    cons: "Mixes concerns and reduces flexibility when changing pricing approaches."
+
+references:

docs/adr/adr-002-pricer-callable-struct.yaml

@@ -0,0 +1,40 @@
+adr_id: 004
+title: "Pricing Method Dispatch via Pricer{A, B, C}"
+status: Accepted
+date: 2025-03-11
+context: |
+  The Hedgehog2.jl pricing framework must support modular pricing techniques that integrate with multiple payoffs, market data configurations, and pricing methodologies.
+  To ensure flexibility and extensibility, pricing calculations must be structured using Julia’s multiple dispatch based on the combination of a `payoff`, `marketInputs`, and `pricingMethod`.
+
+decision: |
+  - Every new pricing method must be implemented by defining a new multiple dispatch method of `Pricer{A, B, C}`.
+  - `Pricer` should not contain a universal pricing function—each `(payoff, marketInputs, pricingMethod)` combination must define its own dispatch specialization.
+  - The pricing logic should **never** be embedded inside `pricingMethod` or `payoff` structs.
+  - Example implementation:
+      ```julia
+      function (pricer::Pricer{VanillaEuropeanCall, BlackScholesInputs, BlackScholesMethod})()
+          S, K, r, σ, T = pricer.marketInputs.spot, pricer.payoff.strike, pricer.marketInputs.rate, pricer.marketInputs.sigma, pricer.payoff.time
+          d1 = (log(S / K) + (r + 0.5 * σ^2) * T) / (σ * sqrt(T))
+          d2 = d1 - σ * sqrt(T)
+          return S * cdf(Normal(), d1) - K * exp(-r * T) * cdf(Normal(), d2)
+      end
+      ```
+
+consequences:
+  positive:
+    - "Ensures modularity: Each pricing method can be added separately using Julia’s multiple dispatch."
+    - "Explicitly defines how new pricing methods must be structured."
+    - "Avoids incorrect designs where pricing logic is inside structs."
+  negative:
+    - "Requires defining a `Pricer{A, B, C}` method explicitly for each combination of payoff, market inputs, and pricing method."
+    - "Less flexible than embedding pricing in the struct, but ensures modularity."
+
+alternatives:
+  - name: "Store pricing logic inside the `AbstractPricingMethod` subtype"
+    pros: "Simplifies structure since each pricing method contains its logic."
+    cons: "Breaks modularity—pricing logic would be tied to the struct rather than using multiple dispatch."
+
+references:
+  - adr-001-payoff.yaml
+  - adr-002-market-inputs.yaml
+  - adr-003-pricing-methods.yaml

docs/adr/adr-003-pricing-methods.yaml

@@ -3,7 +3,7 @@ title: "Greeks Calculation Design"
 status: Accepted
 date: 2025-03-11
 context: |
-  In ADR-002, we introduced `Pricer{P, M, S}` as a callable struct that computes a derivative’s price
+  In ADR-004, we introduced `Pricer{P, M, S}` as a callable struct that computes a derivative’s price
   using a combination of:
     - A `payoff` that subtypes `AbstractPayoff`
     - Market data (`marketInputs`) that subtypes `AbstractMarketInputs`
@@ -51,4 +51,4 @@ alternatives:
     cons: "Less modular, Greeks logic is scattered across functions."
 
 references:
-  - adr-002-pricer-callable-struct.yaml
+  - adr-004-pricer-callable-struct.yaml

docs/adr/adr-004-pricer-callable-struct.yaml

@@ -1,4 +1,6 @@
 adr_index:
-  - "adr-001-structuring-pricing.yaml"
-  - "adr-002-pricer-callable-struct.yaml"
-  - "adr-003-greeks-calculation-design.yaml"
+  - "adr-001-payoff.yaml"
+  - "adr-002-market-inputs.yaml"
+  - "adr-003-pricing-methods.yaml"
+  - "adr-004-pricer-callable-struct.yaml"
+  - "adr-005-greeks-calculation-design.yaml"