There’s an important bit of information here regarding brep structure. A Brep consists of two principal top-level geometric lists, and a large amount of subservient data.

Primarily, a brep is a collection of faces and edges. Edges here are 3D curves and they are shared amongst the faces that use them as boundaries. Edges are only coincident with the faces within tolerance, and sometimes not even that if the brep gets scaled up enough so that small inaccuracies become large inaccuracies.

Below the level of faces and edges we get to the second order geometry:

- Vertices are all the places where edges terminate and meet other edges.
- Loops are edges or collections of edges that are closed and on a single face.
- Trims can be thought of as the edges, but on a per-face basis. I.e. if you have a single edge which is the crease between two faces, there will be two trimming curves associated with it.
- There’s also lists of xyz and uv curves, which
*I imagine* are used to rebuild edges to within tolerances while keeping as close as possible to the original intent of the shape, but honestly I’ve never used these curves.

The Deconstruct Brep component returns the edge curves in whatever order Rhino stores them. It appears to be random, but it’s probably due to some spatial tree lookup or something, in any case, not an order that is useful for anyone except the brep itself.

It seems that Wombat is dealing in Trims instead, which, since they are associated with specific faces, can be easily categorised as u^-, u^+, v^- or v^+, whereas an edge may get conflicting orientations from the adjacent face UV domains and therefore cannot be said to be consistently ‘east’ or ‘north’.