PlanetGraph Access Policies and Property Access Rules

Purpose
Publish Property values as free or paid while preserving Account ownership boundaries.

Authentication
- Send X-API-Key: <key> for service-to-service and agent use.
- Firebase bearer tokens are also accepted.
- Access Policies and Property Access Rules are always scoped to the authenticated Account.

Concepts
1) Access Policy
- A reusable pricing definition owned by one Account.
- The rules object currently uses price, expressed in tokens.

2) Type-level Property Access Rule
- Assigns an Access Policy to matching Properties owned by the same Account.
- A rule is identified by entity (node or edge), entity_type, and property_name.
- Example: node / FundingRound / amount -> Basic Info.

3) Per-Property override
- A Property with an explicit access_policy_id uses that policy instead of its type-level rule.
- Without an explicit assignment or matching type-level rule, the Property value remains owner-only.

Access Policy endpoints
- POST /api/v1/access-policies
- GET /api/v1/access-policies
- PUT /api/v1/access-policies/{policy_id}
- DELETE /api/v1/access-policies/{policy_id}

Create example
POST /api/v1/access-policies
{
  "name": "Basic Info",
  "rules": {"price": "50"}
}

Property Access Rule endpoints
- GET /api/v1/property-access-rules
- PUT /api/v1/property-access-rules
- DELETE /api/v1/property-access-rules/{rule_id}

Create or update example
PUT /api/v1/property-access-rules
{
  "entity": "node",
  "entity_type": "FundingRound",
  "property_name": "amount",
  "access_policy_id": "ACCESS_POLICY_UUID"
}

Ownership and security
- account_id is not accepted in the account-scoped rule request body; PlanetGraph derives it from authentication.
- The selected Access Policy must be owned by the authenticated Account.
- Rule update and deletion are restricted to the authenticated Account.
- Effective type-level rules are matched using Property.owner, so another Account cannot affect a Property by defining the same entity, entity_type, and property_name tuple.
- Attempts to use another Account's policy or rule are rejected without exposing control of that resource.

Effective policy precedence
1) Explicit access_policy_id on the individual Property.
2) Matching type-level Property Access Rule for Property.owner.
3) Owner-only access when neither is configured.

Reading and purchasing
- Listing Properties exposes metadata for visible resources, but locked values are null.
- A zero-token effective policy makes the value freely returnable.
- A positive-token effective policy can be purchased through POST /api/v1/properties/{property_id}/purchase.
- Purchase proceeds are credited to the Property owner, less the platform fee.

Search is separate
Property Access Rules govern whether values are returnable. Property Search Rules govern whether values can be found. Search Rules remain under /api/v1/searchability/property-search-rules.