{"slug": "cognis-when-software-changes-its-knowledge-should-change-with-it", "title": "Cognis — When Software Changes, Its Knowledge Should Change With It", "summary": "At the WeMakeDevs × AWS Bharat Builds Tour First Commit Build Day at Polaris School of Technology, a team built Cognis, an autonomous behavioral verification engine that detects contract drift between a codebase and its surrounding knowledge. Cognis builds an evidence graph from source code, ASTs, documentation, API schemas, dependencies, tests, and CI configuration, then uses AI reasoning to detect contradictions and trace downstream consequences. The team also built Ask Cognis, an Amazon Bedrock-integrated assistant that reasons over repository evidence, and designed self-healing to refuse automatic repairs when evidence contradicts itself.", "body_md": "Software changes. Knowledge doesn't.\n\nAnd that gap is where things start breaking.\n\nAt the WeMakeDevs × AWS Bharat Builds Tour — First Commit, we spent the Build Day at Polaris School of Technology working on a problem that developers eventually face as their codebases grow:\n\nHow do we keep the knowledge surrounding a software system in sync with the software itself?\n\nDocumentation is easy to write once.\n\nKeeping it correct as the code, APIs, SDKs, examples, tests and behaviour evolve is the difficult part.\n\nA seemingly small change can leave behind:\n\n→ outdated documentation\n\n→ broken examples\n\n→ inconsistent API contracts\n\n→ stale SDK guidance\n\n→ incorrect context for AI agents\n\n→ knowledge that no longer reflects reality\n\nWe built Cognis to approach this as a knowledge integrity problem, rather than simply a documentation problem.\n\nWhat is Cognis?\n\nCognis is an autonomous behavioral verification engine for codebase contract drift.\n\nInstead of treating a repository as just a collection of source files, Cognis looks at the different pieces of evidence surrounding the software and tries to understand how they relate to one another.\n\nIt can inspect things such as:\n\nSource code and ASTs\n\nDocumentation\n\nAPI/schema definitions\n\nDependencies\n\nTests\n\nCI configuration\n\nRepository structure\n\nOther evidence discovered during investigation\n\nThe system then builds an evidence graph and uses that information to reason about whether the knowledge surrounding the software still matches its actual behaviour.\n\nThe flow can be thought of as:\n\nCode change → Behaviour change → Broken promise → Downstream consequences → Knowledge repair\n\nThe Cognis Investigation Engine\n\nThe heart of Cognis is its investigation engine.\n\nWhen an investigation begins, Cognis first observes the repository and collects evidence.\n\nThat evidence is normalized and connected into the system's understanding of the codebase.\n\nThe investigation engine can then:\n\nReconstruct behaviour from the available evidence.\n\nIdentify contracts and expected behaviour.\n\nDetect contradictions or drift.\n\nTrace the consequences of the contradiction.\n\nUse AI reasoning to investigate the evidence.\n\nDetermine whether a repair is justified.\n\nVerify the proposed change before allowing it to proceed.\n\nThis makes Cognis more than an AI chatbot that reads a repository and generates an answer.\n\nThe goal is to make the AI reason from evidence about the software, rather than simply relying on what the model thinks should be true.\n\nAsk Cognis\n\nWe also built Ask Cognis, an AI assistant that lets developers interact with their codebase conversationally.\n\nIt is integrated with Amazon Bedrock, allowing Cognis to use a foundation model as part of its reasoning system.\n\nInstead of asking an AI:\n\n\"What do you think this code does?\"\n\nthe idea is to give it the relevant repository evidence and context and ask it to reason from that information.\n\nThis makes the assistant useful not only for answering questions, but also as an interface into Cognis's understanding of the repository.\n\nSelf-Healing — With Restraint\n\nOne of the ideas we cared about most was restraint.\n\nA system capable of modifying software shouldn't blindly \"fix\" something just because an AI model believes it knows the answer.\n\nCognis therefore treats healing as a controlled process.\n\nWhen a contradiction is detected, Cognis can create a healing transaction, plan a potential change, apply it in a controlled environment, and use verification/regression checks before considering the repair safe.\n\nThere is also an important failure condition:\n\nWhen the evidence contradicts itself, Cognis can refuse to repair automatically.\n\nBecause sometimes the smartest action isn't to generate an answer.\n\nIt's to stop.\n\nWe believe this is particularly important for AI-powered developer tools. Giving an AI the ability to modify software also means giving it the ability to recognize when it doesn't have enough evidence to safely do so.\n\nRepository Architecture\n\nWe structured Cognis as a monorepo so that the frontend, reasoning engine and cloud infrastructure could evolve together.\n\ncognis/\n\n│\n\n├── apps/\n\n│   └── web/\n\n│       ├── app/\n\n│       │   ├── dashboard/\n\n│       │   ├── healing/\n\n│       │   └── api/\n\n│       ├── components/\n\n│       │   ├── copilot/\n\n│       │   ├── dashboard/\n\n│       │   ├── healing/\n\n│       │   ├── hero/\n\n│       │   └── scenes/\n\n│       └── lib/\n\n│\n\n├── backend/\n\n│   ├── evidence/\n\n│   │   ├── extractors/\n\n│   │   ├── parsers/\n\n│   │   ├── discovery/\n\n│   │   ├── graph.py\n\n│   │   └── pipeline.py\n\n│   │\n\n│   ├── contracts/\n\n│   │   ├── extractor.py\n\n│   │   └── resolver.py\n\n│   │\n\n│   ├── agent/\n\n│   │   ├── bedrock_client.py\n\n│   │   ├── loop.py\n\n│   │   └── tools.py\n\n│   │\n\n│   ├── verification/\n\n│   ├── healing/\n\n│   │   ├── planner.py\n\n│   │   ├── patcher.py\n\n│   │   ├── transaction.py\n\n│   │   └── immune_memory.py\n\n│   │\n\n│   ├── db/\n\n│   └── orchestrator.py\n\n│\n\n├── infra/\n\n│   └── aws/\n\n│       ├── functions/\n\n│       │   ├── ingress/\n\n│       │   ├── observe/\n\n│       │   ├── engine/\n\n│       │   ├── persist/\n\n│       │   └── status/\n\n│       │\n\n│       ├── statemachine/\n\n│       │   └── pipeline.asl.json\n\n│       └── template.yaml\n\n│\n\n├── docs/\n\n│   ├── ARCHITECTURE.md\n\n│   └── API.md\n\n│\n\n└── .github/\n\n    └── workflows/\n\nThe major layers are:\n\nFrontend\n\nThe Next.js application provides the interactive Cognis experience, dashboard, investigation views, healing interface and Ask Cognis assistant.\n\nEvidence Layer\n\nDiscovers and extracts information from source code, ASTs, documentation, schemas, dependencies, tests and CI.\n\nContract Layer\n\nExtracts and resolves behavioural contracts from the evidence.\n\nCognitive/Agent Layer\n\nRuns the investigation loop and integrates Amazon Bedrock for AI reasoning.\n\nVerification Layer\n\nChecks proposed changes against relevant verification surfaces.\n\nHealing Layer\n\nHandles planning, patching and transaction tracking instead of allowing uncontrolled file modification.\n\nAWS Runtime Layer\n\nRuns the investigation asynchronously through Lambda and Step Functions while using S3 and DynamoDB for persistent state and artifacts.\n\nAWS Integration\n\nAWS wasn't just added as a deployment target — it forms an important part of Cognis's execution architecture.\n\nOur cloud pipeline is:\n\nResult\n\nAmazon API Gateway\n\nProvides the HTTP interface for starting investigations and retrieving investigation status.\n\nAWS Lambda\n\nThe Cognis runtime is divided into separate functions for:\n\nIngress\n\nRepository observation\n\nInvestigation engine\n\nPersistence\n\nStatus retrieval\n\nThis keeps individual responsibilities isolated instead of putting the entire system into one server.\n\nAWS Step Functions\n\nStep Functions orchestrates the investigation lifecycle:\n\nObserve → Engine → Persist\n\nIt also provides retry and failure handling for the individual stages.\n\nAmazon S3\n\nUsed for repository and investigation artifacts, allowing the system to work with larger artifacts without putting everything directly into the database.\n\nAmazon DynamoDB\n\nStores persistent investigation state and Cognis data, including investigation information, evidence-related records, traces and configuration.\n\nAmazon Bedrock\n\nBedrock provides the foundation-model capability used by Cognis's reasoning layer and Ask Cognis assistant.\n\nAWS SAM\n\nWe used AWS Serverless Application Model (SAM) to define the AWS infrastructure as code and deploy the serverless architecture consistently.\n\nChallenges We Faced\n\nBuilding Cognis meant dealing with several different engineering problems at the same time.\n\nA codebase isn't just source code.\n\nUnderstanding a behavioural change can require looking at source files, documentation, schemas, tests, dependencies and CI configuration together.\n\nDesigning a common evidence model that could represent these different sources was one of the core challenges.\n\nGetting an LLM to produce an answer is relatively straightforward.\n\nGetting it to reason about a repository using structured evidence, contradictions and verification constraints is much harder.\n\nWe had to think about how evidence is collected, passed into the reasoning loop and used to determine whether an action is actually justified.\n\nSelf-healing sounds simple until the system is actually allowed to modify files.\n\nA bad AI-generated repair can be worse than the original problem.\n\nThis is why we designed the healing layer around transactions, confidence thresholds and verification rather than directly overwriting files.\n\nConnecting API Gateway, Lambda, Step Functions, S3, DynamoDB and Bedrock into one workflow introduced another layer of complexity.\n\nIAM permissions, service-to-service communication, model configuration, deployment configuration and asynchronous execution all had to work together.\n\nRepository investigation isn't always an instant operation.\n\nInstead of making the user wait for one long HTTP request, we designed the AWS pipeline around Step Functions and persistent investigation state, allowing the investigation to run independently and the frontend to retrieve its progress/results.\n\nWhere Cognis Stands Out\n\nThere are already excellent developer tools for individual problems such as documentation generation, dependency analysis, code search, security scanning and AI coding assistance.\n\nCognis approaches the problem from a different angle.\n\nRather than asking only:\n\n\"Can AI understand my code?\"\n\nwe ask:\n\n\"Can a system continuously determine whether the knowledge surrounding my software is still true?\"\n\nThe distinction is important.\n\nMost developer tools focus on a particular surface.\n\nCognis is designed around the relationship between surfaces.\n\nFor example:\n\nSource Code\n\n     │\n\n     ▼\n\nBehaviour\n\n     │\n\n     ▼\n\nAPI / Contract\n\n     │\n\n     ├── Documentation\n\n     ├── Examples\n\n     ├── Tests\n\n     ├── SDK guidance\n\n     └── AI context\n\nIf the implementation changes but the surrounding knowledge doesn't, Cognis treats that as a potential knowledge integrity problem.\n\nThe second difference is the investigation loop.\n\nCognis isn't designed to immediately generate a patch whenever an LLM sees something suspicious.\n\nIt follows a process closer to:\n\nObserve → Gather Evidence → Detect Drift → Investigate → Assess Confidence → Verify → Repair\n\nAnd importantly:\n\nContradictory evidence → Stop\n\nThat idea of AI with restraint is central to what we wanted Cognis to become.\n\nThe Bigger Vision\n\nThe long-term vision is bigger than documentation.\n\nWe want Cognis to become a living knowledge layer for software.\n\nA layer connecting software behaviour with everything that depends on understanding that behaviour:\n\nCode ↔ APIs ↔ Documentation ↔ SDKs ↔ Examples ↔ Developer Portals ↔ Tests ↔ AI Agents\n\nAs software changes, Cognis could continuously ask:\n\n\"What else became untrue because of this change?\"\n\nAnd instead of simply telling the developer that something is wrong, it could provide the evidence, trace the consequences, explain the reasoning and, when sufficiently confident, help restore the affected knowledge safely.\n\nBuild Day\n\nThis project started as an idea during the WeMakeDevs × AWS Bharat Builds Tour — First Commit at Polaris School of Technology.\n\nWe got the opportunity to meet Kunal Kushwaha and Hitesh Choudhary, and learn from the AWS workshop with Jatin Mehrotra, Veeramani and Arkodyuti Saha.\n\nBuilding alongside developers, learning from people actively contributing to the ecosystem, and turning an idea into a working prototype within the same environment was an experience we'll remember.\n\nHuge thanks to WeMakeDevs, AWS and Polaris School of Technology for creating a space where we could experiment, learn and simply build.\n\nCognis is our attempt at answering one question:\n\nWhat if software could tell you when the knowledge around it stopped being true — and safely help restore it?\n\nWe're only getting started.", "url": "https://wpnews.pro/news/cognis-when-software-changes-its-knowledge-should-change-with-it", "canonical_source": "https://dev.to/sanjeev_75510/cognis-when-software-changes-its-knowledge-should-change-with-it-lcf", "published_at": "2026-09-20 13:45:26+00:00", "updated_at": "2026-09-20 13:54:16.509028+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-tools", "ai-infrastructure", "artificial-intelligence"], "entities": ["Cognis", "Ask Cognis", "Amazon Bedrock", "AWS", "WeMakeDevs", "Polaris School of Technology"], "alternates": {"html": "https://wpnews.pro/news/cognis-when-software-changes-its-knowledge-should-change-with-it", "markdown": "https://wpnews.pro/news/cognis-when-software-changes-its-knowledge-should-change-with-it.md", "text": "https://wpnews.pro/news/cognis-when-software-changes-its-knowledge-should-change-with-it.txt", "jsonld": "https://wpnews.pro/news/cognis-when-software-changes-its-knowledge-should-change-with-it.jsonld"}}