Relationship governance

This contract separates evidence, sensing, operational staging, and human relationship truth.

The goal is to let agents become increasingly useful without letting an agent-generated interpretation silently become the authoritative state of a human relationship.

Current authority map

Layer	Current surface	Authority
Raw/social evidence	local socials data lake	canonical evidence substrate only
Adapter orchestration / normalization	matuteiglesias/people_intel	canonical evidence pipeline only
Agent sensing	ChatGPT Relationship Scout and related agents	proposals / judgment artifacts only
Operational queue	Google Sheet Relational Operations	staging, noncanonical
Human relationship state	Google Sheet CRM, tab PERSONAS	canonical current human state
Historical inventory	Google Sheet Lista Personas	reference only
Future repo mirror	private repo/file TBD	candidate snapshot only until explicit promotion

projects stores this authority contract and schemas. It does not store the people rows themselves.

Core rule

Evidence can update what we know about a person. It cannot by itself decide what the relationship means.

people_intel and the socials data lake can own source observations, identifiers, affiliations, roles, timestamps, URLs and normalized evidence. GPT sensing can own a proposal such as “this relationship appears timely to reactivate because artifact X now exists.” The canonical fields describing whether the relationship is active, dormant, waiting, important, not worth contacting, or what to do next remain human-owned until accepted.

Agent write boundary

Agents may autonomously:

• inspect authorized evidence;
• synthesize person × project crossovers;
• emit ranked sensing maps;
• detect changed circumstances;
• propose relationship status, priority, tags or next actions;
• attach evidence references and a reason;
• expire or supersede their own stale proposals.

Agents may not silently overwrite canonical human fields such as relationship status, priority, next action, waiting-on state, do-not-contact state or human notes.

The safe write primitive is a relationship.sensing-proposal@1 artifact. A human decision can accept, reject, modify or defer it using relationship.human-decision@1 semantics.

Column/field authority

Human-owned

• relationship status
• priority
• relationship summary / interpretation
• next action
• waiting on
• do-not-contact
• human notes
• accepted tags

Evidence-owned

• source identifiers
• source references
• observed affiliations
• observed roles
• observed activity timestamps
• evidence/run identity

Human corrections can supersede bad evidence mappings; the underlying source observation should remain traceable.

Agent-proposed

• proposed status
• proposed priority
• proposed next action
• trigger
• rationale
• evidence references
• confidence
• proposal expiry

Derived

• freshness
• attention bucket
• staleness
• count of open proposals

Derived fields are conveniences, not authority.

Intended flow

social / source evidence
        ↓
local socials data lake
        ↓
people_intel adapters + normalized evidence
        ↓
GPT / other sensing producers
        ↓
relationship.sensing-proposal@1
        ↓
      HUMAN
 accept / reject / modify / defer
        ↓
CRM / PERSONAS canonical relationship state
        ↓
future sensing context

The feedback loop is deliberate: once a human updates the relationship state, later sensing should consume that state so agents stop rediscovering already-decided context and avoid duplicate outreach recommendations.

Relationship Scout output evolution

The existing sensing-map/action-layer format is already useful. The governed version should additionally emit, for candidates that materially changed:

• stable person_ref when resolvable;
• trigger;
• evidence_refs;
• current canonical-state timestamp if known;
• proposed state/priority/next-action delta;
• proposal_id;
• expiry/supersession semantics.

A full 30-person awareness map does not need to create 30 canonical relationship updates. Only material deltas should become proposals.

Google Sheets integration

Direct automated Sheet synchronization is intentionally not required for v1.

For now, the contract is enough to ensure future integration does not create two masters. A later adapter may:

1. read current CRM human state;
2. export/version a machine-readable snapshot;
3. append agent proposals to a dedicated proposal surface;
4. read explicit human decisions;
5. materialize accepted state back into the canonical representation.

If a private-repo file later becomes the canonical state, that is a migration, not an incidental sync feature. The migration must specify conflict resolution, edit capture, provenance, rollback and which direction is authoritative.

Privacy and repository boundary

projects should contain only schemas, logical surface names, authority rules and producer topology. It should not contain the CRM rows, social source dumps or private relationship notes.

The socials data lake may remain local-only. people_intel may continue orchestrating adapters around it without forcing the raw data into GitHub.

Why this composes

This creates a safe compounding loop:

better evidence
→ better sensing
→ better agent proposals
→ better human state
→ agents remember decisions
→ better relationship maintenance
→ more collaboration / sources / opportunities
→ better evidence

The important constraint is that agent quality can compound without diluting human authority over human relationships.