What has worked well in practice is giving the agent a directory, and tell it to make independent markdown files for facts/findings it locates - with each file having front-matter for easy search-ability.

This de-complects most tasks from "research AND store iteratively in a final document format" to more cohesive tasks "research a set of facts and findings which may be helpful for a document", and "assemble the document".

Only a partial mitigation, but find it leads to more versatile re-use of findings, same as if a human was working.

I wonder if that is some type of fallback for errors querying the model, or k2 actually created the html/css to display that.

(15mph residential access road - top right) (25 mph farmland road - bottom) (50mph country highway - left and right)

Previously, only drivers from the 15mph and 25mph roads had to stop!

Visibility coming from the south would also be terrible to check for incoming highway drivers (left is blocked by foliage, right the road curves out of sight), so getting the highway drivers to slow down is a welcome improvement here.

There is also not enough space to add at the intersection here either, its seemingly bordered entirely by private land.

The approach from Chawathe et. al splits nodes from the before/after trees into chains by their label in the syntax grammar, and then runs myers’ longest common subsequence on each pair of chains. Some parameters t, f are used to have an approximate ‘equals’ method for subtrees.

This iteratively builds a set of matchings between equivalent nodes from the old and new trees. Here’s the paper https://dl.acm.org/doi/10.1145/235968.233366

I’d be curious to see if this approach handles re-ordering of nodes better. The ‘fastMatch’ algorithm described above will typically miss matching cases where a node that is not order sensitive (i.e a function in a namespace can be moved somewhere else in that namespace).