Expand relationship model with typed edges beyond lineage

[ravisuhag]

Context

Meteor currently only captures upstream/downstream lineage relationships. For AI agents to reason about organizational context, we need a richer vocabulary of relationships between assets.

Scope

Define and implement support for typed relationship edges:

• owns — ownership relationships (team/user → asset)
• reads / writes — access patterns (job/service → asset)
• documented_by — documentation links (asset → doc page)
• tested_by — data quality test coverage (asset → test/probe)
• derived_from — semantic derivation beyond pipeline lineage
• depends_on — service and infrastructure dependencies

Approach

1. Proto schema changes — Extend the asset protobuf definitions in raystack/proton to support typed edges with metadata. This is the contract between Meteor and Compass and should be designed first.
2. Update the asset model — Ensure models/Record can carry typed relationships alongside existing lineage.
3. Update the stream/pipeline — Processors and sinks should pass through typed relationships without losing them.

Boundary

Meteor extracts and delivers typed relationships as raw observations. Entity resolution — matching these observations to unified entities in the graph — happens in Compass. Meteor's job is to capture as many relationships as the source exposes, annotated with enough context for Compass to resolve and store them.

Why

Lineage alone answers "where does data flow?" but AI agents also need to know "who owns this?", "what tests cover this?", "where is this documented?", and "what services depend on this?" Each relationship type enables different reasoning patterns.

Dependencies

• Proto schema design in raystack/proton
• Compass must evolve ingestion to store typed relationships

References

• Meteor Roadmap — From Records to Graph