Code intelligence has escaped the code

BrokkAi released Bifrost v0.14.4, a code-intelligence tool that correlates Java configuration-accessor calls with entries in explicitly named .properties files, so that a call such as config.get("db.url") is linked to the db.url entry in a declared document rather than to any matching string literal. The release expresses the relationship in RQL, pairing the :code side, which selects the accessor and binds arguments to its first parameter through proven call resolution, with the :configuration side, which selects property entries. Bifrost reports duplicate keys as "ambiguous" and returns incomplete diagnostics for unreadable documents, undecodable arguments, and keys built from constants or dynamic values, following what BrokkAi calls its "honest incompleteness" principle: an empty result with incomplete diagnostics does not establish that no relationship exists.

Code intelligence has escaped the code A surprising amount of program behavior is defined by what is outside the program. Database URLs, feature flags, and library settings sit in configuration files or environment variables, while the code reading them may make some half-assed assumptions on what comes out on the other end. Strings are an example of a horrible "anything" type and should more often than not be encoded into more specific types, e.g., URL, semantic version class, etc. If we want code intelligence to explain what an application does, those files become part of the question. For example, we might want to assert that, before deployment, every required configuration lookup must resolve to exactly one valid entry in the application’s declared production configuration file. For example, Bifrost v0.14.4 https://github.com/BrokkAi/bifrost/releases/tag/v0.14.4?ref=blog.brokk.ai correlates Java configuration-accessor calls with entries in explicitly named .properties files. The recordings below use the public release: Suppose our application reads configuration through AppConfig.get String key : void connect AppConfig config, Audit audit { String url = config.get "db.url" ; String pool = config.get "db.pool" ; audit.get "db.url" ; } And we have this document: src/main/resources/app.properties db.url=jdbc:postgresql://db/app db.user=app We want to connect the first call to the db.url entry. We also want to explain why the other calls don’t qualify. Searching for the literal "db.url" finds it in both calls. Searching for methods named get finds those too. Neither tells us which method resolves to the configuration document we mean. That would be an impressive amount of confidence and coincidence for two equal strings. Instead, let's express their relationship in RQL https://bifrost.brokk.ai/code-querying/?ref=blog.brokk.ai : correlate :relation configuration-key :documents "src/main/resources/app.properties" :code call-input :parameter-index 0 call-sites-to :proof proven enclosing-decl inside class name "AppConfig" method name "get" :configuration configuration-facts :format properties :node-kind member The :code side selects the accessor and asks for arguments bound to its first parameter through proven call resolution. The :configuration side selects property entries. The :relation connects a plain string-literal key to the matching entry inside the declared document. So config.get "db.url" pairs with db.url=... . The "db.pool" call has no matching entry in this file. audit.get "db.url" resolves to a different method. An identically named property in another file stays outside the relationship unless we explicitly declare that file . The result retains both locations and their provenance, giving us something we can inspect and navigate. The important boundary or "narrowing" of the query is in supplying the document path. The query does not statically determine which file the application loads at runtime or which value wins after overrides. For correctness-sake, duplicate keys result in an "ambiguous" outcome. Unreadable documents and arguments the relation cannot decode produce incomplete diagnostics. If the key comes from a constant or a dynamically constructed value, this first implementation cannot establish the same relationship. An empty result accompanied by incomplete diagnostics tells us where the analysis stopped. It does not establish that no relationship exists. For an agent, this makes a useful difference. It can follow an explicit relationship between a configuration read and an authored setting, inspect both sides, and carry the remaining uncertainty into its answer. This is part of Bifrost's "honest incompleteness" principle when determining a query result. For the example in this blog, the configuration-key relation used here supports Java calls with plain string-literal keys and explicitly named .properties files. However, Bifrost also queries JSON, YAML, TOML and XML, with separate relations for other connections between code and configuration. As previously mentioned, the does not infer runtime file loading, framework binding or environment overrides. Bifrost also powers SlopCop https://slopcop.com/?ref=blog.brokk.ai , where slopcop check or its MCP equivalent brings static analysis into a coding agent’s edit-and-check loop. A number of CVEs relating to vulnerable dependencies only trigger when certain configuration settings are enabled. For example, CVE-2022-22947 https://spring.io/security/cve-2022-22947/?ref=blog.brokk.ai in Spring Cloud Gateway required the Gateway Actuator endpoint to be enabled, exposed, and unsecured. Log4j's CVE-2021-45046 https://logging.apache.org/security.html?ref=blog.brokk.ai involved a non-default Pattern Layout containing a Thread Context Lookup such as $${ctx:loginId} , combined with attacker-controlled context data. Without these pre-conditions in the application configuration, the affected dependency is dormant and not an immediate threat to the code that uses it. Code intelligence has escaped the code and, for now, it knows exactly which file it was allowed to visit.