> ## Documentation Index > Fetch the complete documentation index at: https://docs.amnify.ai/llms.txt > Use this file to discover all available pages before exploring further. # Context > What Amnify knows about your organization, and how it decides when to ask you something. Two teams can get the same finding and be right to treat it differently. A public bucket is a breach in one organization and a static site in another. The knowledge base is where Amnify learns which one you are. Severity itself is not up for negotiation: it is rated against established security frameworks. What your context decides is whether a finding applies to you at all, and what gets fixed first. It is built from two things: the **documents** you upload, and the **questions** you answer. ```mermaid theme={null} flowchart TB DOC["Knowledge sources
policies, standards, exceptions"] ANS["Answers
to the questions Amnify asks"] DEC["Decisions
what your organization has settled"] FIND["Findings
code, secrets, dependencies, IaC, cloud, pentest"] LNK["Clusters
findings sharing one cause or one fix"] DOC --> DEC ANS --> DEC DEC -.->|"ranks, suppresses
or escalates"| FIND FIND --> LNK LNK --> FIND ``` ## Knowledge sources Upload the security documents your organization already has: policies, standards, architecture decisions, exception registers. PDF, Word, plain text and Markdown. An agent reads them for two purposes. Where a document already settles a case, Amnify applies it and stays quiet. You are not asked about something you have already written down. Where a question is still needed, the answer Amnify believes is yours is pre-filled, with the passage it came from quoted as the citation. Each document shows how many decisions cite it. Removing one stops it being used immediately, and existing citations stay readable. ## Questions A question is a decision Amnify needs and will not infer for you. Each one is short: pick one option, pick several, or write your own, and every question names the findings it affects. They are grouped into **Needs input**, **Assigned to you**, and **Answered**. ### When Amnify asks All three of these have to hold. A single occurrence is triaged on its own. A pattern repeating across findings is a sign of an organizational preference worth capturing once and reusing. Whether the finding stands at all, how urgent it is for you, or how its fix should be planned. If the answer changes nothing, there is no question. Neither your documents nor a decision from an earlier answer covers the case. Amnify checks what it already knows before it asks. ### The one exception Amnify also asks when a document **does** answer the question, but what it recommends conflicts with security best practice. It neither follows the document quietly nor overrides it quietly. Instead it: * pre-fills the answer the document implies, * marks it as conflicting and shows the passage it is based on, * warns you before you confirm it. You can still choose the document's answer, and sometimes that is the right call for your organization. What Amnify will not do is let a decision against best practice be inherited in silence from a file. A person makes it, and the record says so. ### When Amnify stays quiet When a document or an earlier decision already settles it, the answer is applied without asking. Silence is the goal. The first week is the loudest one, and every answer you give removes a class of future question. ## An answer becomes a decision ```mermaid theme={null} flowchart TB P["Pattern across
two or more findings"] --> Q["Question"] D["Your documents"] -->|"pre-filled answer
with a citation"| Q Q --> A["Your answer"] A --> DEC["Decision, in one sentence"] DEC --> NOW["Applied now to
the findings it affects"] DEC --> NEXT["Reused on every
similar future finding"] ``` Until you answer, the findings a question gates are held back: not listed, not counted in your posture, and not planned for a fix. Answering releases them in the same moment. An answer keeps a finding **Open** when it is a real gap for you, **Suppresses** it when your answer waives it, and becomes a decision reused on everything similar. Answering applies immediately, with no separate re-evaluation step. The findings it affects are re-evaluated on the spot, and for Critical and High findings a remediation is planned right away. If you correct a pre-filled answer, your correction wins over the document permanently. ## Clusters The knowledge base also records how findings relate to each other. An agent links them and states which kind of relationship it is, with a confidence and a one line reason. | Link | Meaning | Example | | ------------------- | ----------------------------------------------------------- | ------------------------------------------------------------------------------- | | **Same root cause** | One underlying issue surfacing in different places | A leaked credential, and the over permissive role that makes the leak dangerous | | **Same resource** | Two findings about the same thing, seen at different layers | A cloud misconfiguration, and the infrastructure as code that created it | | **Manifests in** | One finding is the direct manifestation of another | A penetration test proving exploitable what a code finding predicted | The connected group is a **cluster**, and one remediation covers the whole cluster. This is what stops a fix closing the symptom while leaving the cause to recreate it. ## Where a finding originates Amnify also records where each finding comes from: a repository file and line range today, with documentation and ticket references following the same shape. It turns a finding about a running system into a finding about the code that produced it, so the fix can be made where it lasts. A cloud misconfiguration traced to the infrastructure as code that created the resource, and a penetration test finding traced to the handler that is exploitable, are the same mechanism. It is also what forms clusters: finding out where two issues originate is what reveals they originate in the same place. ## What this changes The severity of an issue is fixed by the frameworks. Whether it is a real gap for you, and where it sits in the queue, is your call. Findings sharing a cause are one cluster with one fix, not several tickets that each half solve it. Because a finding knows where it originates, the fix can be made at the origin rather than at the symptom. Every answer removes a class of future question, and every document removes questions before they are asked.