Skip to content

Add AccessGrant and CalendarAvailability ontology schemas - #1095

Open
AlexTourski wants to merge 2 commits into
mainfrom
codex/add-access-grant-calendar-availability
Open

Add AccessGrant and CalendarAvailability ontology schemas#1095
AlexTourski wants to merge 2 commits into
mainfrom
codex/add-access-grant-calendar-availability

Conversation

@AlexTourski

@AlexTourski AlexTourski commented Jul 26, 2026

Copy link
Copy Markdown

Summary

Adds two proposed W3DS JSON Schema draft-07 ontologies:

  • AccessGrant for canonical owner-to-grantee authorization and non-authoritative discovery references.
  • CalendarAvailability for explicit owner-defined booking windows.

The schemas use newly generated UUIDv4 identifiers:

  • AccessGrant: 15d24c04-a4f3-4e45-a00e-0123926fbc87
  • CalendarAvailability: a92c3675-dbc8-44f6-b24e-520eeadb8864

This PR is intentionally a draft. Calex will not write records using these schema IDs until W3DS maintainers approve the model and merge/register the schemas.

Motivation

Calex needs interoperable records for calendar visibility, delegated event operations, explicit availability windows, and public booking policy without introducing a local authorization database or copying authoritative calendar data outside users' eVaults.

Maintainer questions / blockers

  1. Is the canonical/reference AccessGrant pattern appropriate for cross-eVault discovery?
  2. May a certified post-platform create a non-authoritative reference in a grantee's eVault?
  3. Should raw AccessGrant and CalendarAvailability records remain owner-only under the current combined read/write ACL semantics?
  4. Are namespaced permissions such as calendar:viewBusy acceptable?
  5. Where should delegated actor and authorizing grant provenance live: MetaEnvelope metadata, audit records, or CalendarEvent fields?
  6. Does grant creation/revocation require an owner signature flow?
  7. What shared provisional-hold and atomic compare-and-create mechanism should prevent double booking?
  8. Are draft-07 conditional keywords (if/then, const) supported by the deployed Ontology validation path?

Scope

Only two new files under services/ontology/schemas/ are added. No existing schema, runtime service, workflow, or deployment configuration is changed.

Summary by CodeRabbit

  • New Features
    • Added formal validation contracts for access grants, including canonical and reference grant types.
    • Added conditional validation for grant permissions, recipients, delegation, status, revocation details, and validity periods.
    • Added a calendar availability schema covering booking policies, verification holds, daily limits, lifecycle status, and cancellation details.
    • Schemas now reject unsupported fields and enforce required formats, types, and value constraints.

@coderabbitai

coderabbitai Bot commented Jul 26, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

📝 Walkthrough

Walkthrough

Adds JSON Schema contracts for AccessGrant and CalendarAvailability, including field constraints, required properties, variant validation, lifecycle conditions, and restrictions on undeclared properties.

Changes

Access grant schema

Layer / File(s) Summary
AccessGrant shared contract
services/ontology/schemas/accessGrant.json
Defines the schema metadata, shared fields, validation constraints, and required properties for AccessGrant.
AccessGrant variants and conditionals
services/ontology/schemas/accessGrant.json
Validates canonical and reference grant shapes, conditional grantee fields, revoked timestamps, and disallows undeclared properties.

Calendar availability schema

Layer / File(s) Summary
CalendarAvailability validation
services/ontology/schemas/calendarAvailability.json
Defines fields, required properties, booking-policy conditions, cancellation conditions, and additional-property restrictions.

Estimated code review effort: 3 (Moderate) | ~25 minutes

Suggested reviewers: coodos

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Description check ⚠️ Warning The description covers summary, motivation, blockers, and scope, but omits required template sections like issue number, type, testing, and checklist. Add the missing template sections: issue number, type of change, testing details, and the checklist items, or note why each is unavailable.
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly summarizes the two new ontology schema additions in the PR.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch codex/add-access-grant-calendar-availability

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@coodos
coodos marked this pull request as ready for review July 27, 2026 07:37
@coodos
coodos self-requested a review as a code owner July 27, 2026 07:37

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 4

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@services/ontology/schemas/accessGrant.json`:
- Around line 241-264: Add a complementary else branch to the conditional
governing revokedAt for non-reference grants: when status is "active", constrain
revokedAt to null, while preserving the existing date-time validation for
revoked grants in the conditional around isReference and status.
- Around line 82-84: Update the delegationAllowed definition and its related
oneOf schemas, including CanonicalAccessGrant and AccessGrantReference, so the
schema accurately reflects whether delegation is supported: allow true values
through the applicable branch if delegation is intended, or remove the
authoritative required field when delegation is unavailable. Ensure no branch
simultaneously requires delegationAllowed to be false while another forbids the
key.

In `@services/ontology/schemas/calendarAvailability.json`:
- Around line 83-89: Update the calendar availability schema’s lifecycle
validation around the status and cancelledAt definitions so active records
require cancelledAt to be null. Add the corresponding else branch while
preserving the existing cancellation-timestamp requirement for non-active
states.
- Around line 15-21: Update the calendar availability record-validation layer
for the startDate and endDate fields to parse both date-time values and reject
records where endDate is less than or equal to startDate. Preserve the existing
schema property validation while enforcing that availability windows are
strictly forward-moving.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: b889e48f-59af-4d45-92c2-abe06fd34cb1

📥 Commits

Reviewing files that changed from the base of the PR and between 8a4fc83 and 181ced8.

📒 Files selected for processing (2)
  • services/ontology/schemas/accessGrant.json
  • services/ontology/schemas/calendarAvailability.json

Comment on lines +82 to +84
"delegationAllowed": {
"type": "boolean"
},

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

delegationAllowed can never be true — the field is effectively dead.

CanonicalAccessGrant forces delegationAllowed to const: false while also requiring the key, and AccessGrantReference forbids the key entirely. Since these are the only oneOf branches, no valid AccessGrant instance can have delegationAllowed: true. If delegation support is intended, make the value configurable here; if delegation is unavailable, avoid exposing an authoritative, required field that upstream/downstream consumers might treat as controllable.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@services/ontology/schemas/accessGrant.json` around lines 82 - 84, Update the
delegationAllowed definition and its related oneOf schemas, including
CanonicalAccessGrant and AccessGrantReference, so the schema accurately reflects
whether delegation is supported: allow true values through the applicable branch
if delegation is intended, or remove the authoritative required field when
delegation is unavailable. Ensure no branch simultaneously requires
delegationAllowed to be false while another forbids the key.

Comment on lines +241 to +264
{
"if": {
"properties": {
"isReference": {
"const": false
},
"status": {
"const": "revoked"
}
},
"required": [
"isReference",
"status"
]
},
"then": {
"properties": {
"revokedAt": {
"type": "string",
"format": "date-time"
}
}
}
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Revocation timestamp only validated one-way.

This conditional forces revokedAt to a date-time string when status == "revoked", but there's no complementary constraint forcing revokedAt to be null when status is "active". An active canonical grant could carry a stray non-null revokedAt, which is an inconsistent state.

♻️ Proposed fix: add an else branch
     {
       "if": {
         "properties": {
           "isReference": {
             "const": false
           },
           "status": {
             "const": "revoked"
           }
         },
         "required": [
           "isReference",
           "status"
         ]
       },
       "then": {
         "properties": {
           "revokedAt": {
             "type": "string",
             "format": "date-time"
           }
         }
+      },
+      "else": {
+        "properties": {
+          "revokedAt": {
+            "type": "null"
+          }
+        }
       }
     }
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
{
"if": {
"properties": {
"isReference": {
"const": false
},
"status": {
"const": "revoked"
}
},
"required": [
"isReference",
"status"
]
},
"then": {
"properties": {
"revokedAt": {
"type": "string",
"format": "date-time"
}
}
}
}
{
"if": {
"properties": {
"isReference": {
"const": false
},
"status": {
"const": "revoked"
}
},
"required": [
"isReference",
"status"
]
},
"then": {
"properties": {
"revokedAt": {
"type": "string",
"format": "date-time"
}
}
},
"else": {
"properties": {
"revokedAt": {
"type": "null"
}
}
}
}
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@services/ontology/schemas/accessGrant.json` around lines 241 - 264, Add a
complementary else branch to the conditional governing revokedAt for
non-reference grants: when status is "active", constrain revokedAt to null,
while preserving the existing date-time validation for revoked grants in the
conditional around isReference and status.

Comment on lines +15 to +21
"startDate": {
"type": "string",
"format": "date-time"
},
"endDate": {
"type": "string",
"format": "date-time"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift

🧩 Analysis chain

🏁 Script executed:

#!/usr/bin/env bash
set -euo pipefail

# Locate CalendarAvailability ingestion/validation paths and confirm they reject
# records whose endDate is equal to or before startDate.
rg -n -C3 -g '*.js' -g '*.ts' \
  'a92c3675-dbc8-44f6-b24e-520eeadb8864|CalendarAvailability|startDate|endDate' \
  services

Repository: MetaState-Prototype-Project/prototype

Length of output: 175


🏁 Script executed:

#!/usr/bin/env bash
set -euo pipefail

echo "Repo files matching calendarAvailability:"
fd -a 'calendarAvailability\.json$|calendar.*availability|availability.*calendar' . || true

echo
echo "Schema excerpt:"
if [ -f services/ontology/schemas/calendarAvailability.json ]; then
  cat -n services/ontology/schemas/calendarAvailability.json
fi

echo
echo "Broader calendar/availability references:"
rg -n -i -C2 -g '*.js' -g '*.ts' -g '*.json' 'calendarAvailability|CalendarAvailability|calendar.?availability|availability.*calendar|booking.?window|startDate|endDate' . || true

Repository: MetaState-Prototype-Project/prototype

Length of output: 14985


Reject inverted availability windows.

endDate <= startDate passes this schema because JSON Schema Draft-07 validates the properties individually but has no native keyword for comparing two date-time fields. Enforce endDate > startDate in the record-validation layer.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@services/ontology/schemas/calendarAvailability.json` around lines 15 - 21,
Update the calendar availability record-validation layer for the startDate and
endDate fields to parse both date-time values and reject records where endDate
is less than or equal to startDate. Preserve the existing schema property
validation while enforcing that availability windows are strictly
forward-moving.

Comment on lines +83 to +89
"cancelledAt": {
"type": [
"string",
"null"
],
"format": "date-time"
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win

Require cancelledAt to be null while active.

status: "active" currently accepts a cancellation timestamp. Add an else branch so lifecycle state cannot be contradictory.

Proposed fix
       "then": {
         "properties": {
           "cancelledAt": {
             "type": "string",
             "format": "date-time"
           }
         }
+      },
+      "else": {
+        "properties": {
+          "cancelledAt": {
+            "type": "null"
+          }
+        }
       }

Also applies to: 152-170

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@services/ontology/schemas/calendarAvailability.json` around lines 83 - 89,
Update the calendar availability schema’s lifecycle validation around the status
and cancelledAt definitions so active records require cancelledAt to be null.
Add the corresponding else branch while preserving the existing
cancellation-timestamp requirement for non-active states.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant