Cubyts AI platform powers your SDLC with state of the art AI technology with clear focus on predictable and high quality of outcomes delivered by SDLC teams.
The core architecture of Cubyts AI platform is driven by four key layers, which serve as the nerve center of the entire platform:
Integration layer:
The integration layer acts as the data pipeline for the Cubyts AI platform; this layer governs the integration with the Systems of records in an enterprise landscape, extracts data from the systems of records using APIs and pushes the data to the data lake. The key characteristics of this layer are as follows:
1.1 Technology: The data extraction is done either using PAT (Personal access tokens) or oAuth/App based integration depending on the type of the tool and the nature/intent of the integration.
1.2 Integration with project management tools: Cubyts AI supports integration with Jira (Cloud and Data centre) and ADO Boards to extract the planning data e.g. information in the product backlog, planning boards, sprint information (present and future), etc. This provides Cubyts AI the necessary context to understand the plan behind any job.
1.3 Integration with requirements/definition tools: Cubyts AI supports integration with Figma, Google Drive, One Drive and Confluence to extract the nature of the job e.g. functional specification, technical specification, UI/UX designs etc. This provides Cubyts AI the necessary context to understand the intent behind any job.
1.4 Integration with code repositories: Cubyts AI supports integration with Github (Free/Team/Enterprise), Gitlab (Self hosted/Cloud), and Bitbucket (Cloud/Data centre) to extract the code built for the intent. This provides Cubyts AI the necessary context to understand the reasons behind the existence of a codebase (Note: The architecture will be extended to support SVN as the code repository).
1.6 Integration with support tools: Cubyts AI supports integration with Jira, Freshdesk and Jira Service Management to extract customer feedback. This provides Cubyts AI the necessary context to understand the voice of the customer and trace it back to the codebase and intent.
Data lake layer:
The platform builds a massive data lake by extracting multiple raw data points from the aforementioned tools. This acts as a baseline input for the other layers of the platform.
Semantic (Knowledge) graph layer:
The data points in data lake are converted to a semantic knowledge consisting of inferred data points and code from the aforementioned tools. This establishes the relationship (and the relationship strength) between artefacts (e.g. Work items from Jira, Design sections from Figma, Code branch/PR from Github, CI/CD job from Jenkins, Support tickets from JSM, etc.). The knowledge graph has two distinct parts (that are connected via edges):
3.1 The data graph: The data graph connects the critical data items (and associated data points) from project management, support, CI/CD and requirement tools. This enables deeper context understanding when the graph traversal is done to unearth inferences.
3.2 The AST code graph: The code part of the graph is an Abstract Syntax Tree representation of the codebase (behaves like a compiler) optimized for .NET, JAVA, JavaScript, Golang and Ruby; this makes the RAG factories and LLMs behave and think like a compiler.
AI (RAG) Factories:
The AI (RAG) factories (based on the expected tasks) leverages the knowledge graph as the semantic context layer with state of the art prompt layer for the various solutions that are possible using the Cubyts platform. A few examples of RAG factories are outlined below:
4.1 Factory for specification quality: This factory focuses on ascertaining the quality of input requirements/user stories based on the specified benchmarks.
4.2 Factory for build quality: This factory focuses on ascertaining the quality of build plan based on the specified benchmarks.
4.3 Factory for specification - code drift: This factory focusses on determination of relevant specification for a code base in branch/PR and then determines the drift between the code base and the specification.
4.4 Factory for code dependency: This factory focuses on discovering the dependency mishaps introduced by a developer in a PR/Branch which may affect dependent codebases in other PRs.
4.5 Factory for code quality based on standards: This factory focuses on evaluating every commit and discovering the issues in the code based on the specified enterprise standards.
4.6 Factory for code explanation: This factory focuses on building the semantic meaning of a codebase based on the ASTs, the outcome of the factory is used by other factories to draw their inferences.
Adoption of this architecture
Health represents the outcome-oriented layer of governance. While flags detect deviations and explain root causes, health answers higher-order questions:
1.1 Is delivery on track right now?
1.2 Are outcomes improving over time?
1.3 Is today’s work creating tomorrow’s risk?
Health converts thousands of low-level signals into decision-ready indicators that leaders, managers, and teams can act on confidently.
Reports provide topic-based, investigative views across the software delivery lifecycle. While health reports highlight what is at risk, deep-dive reports explain why—by enabling structured drill-downs into delivery execution, code changes, contributor actions, and audit outcomes.
2.1 Delivery reports govern how work progresses through the delivery system.
2.2 Code reports explain how delivery intent materialises in code.
2.3 Team reports connect delivery and code activity to people and ownership.
2.4 Audit reports capture deviations from defined governance expectations.
Flags Cubyts Flags introduce a unified governance mechanism that continuously monitors delivery execution, feature readiness, and code quality. Together, Process Flags, Feature Flags, and Code Flags form an integrated system that governs how software is delivered, what is delivered, and how it is implemented—in real time and at scale. Flags can automatically discover 4 types of drifts:
1.1 Process drift: Deviation from established processes causing missed deadlines, wasted effort, Reduced team efficiency, etc.
1.2 Code drift: Technology and code quality drifts resulting in increased debugging time, delayed delivery, and higher unknown technical debt, etc.
1.3 Audit drift: Missed adherence to info sec, regulatory standards resulting in audit risks, etc.
1.4 Feature drift: Deviation from PRDs, User stories, Feedback resulting in unplanned work, delayed launches & unrealized customer expectations.
Repository is the knowledge assistant for Scrum teams, offers the following assistance to the scrum team:
3.1 Aggregates all the documents linked in the various systems of records.
3.2 Provides context to all the documents (e.g. all the document references in a story or a task).
3.3 Discovers all the related documents in the same context.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article