Skip to content

AIASM-14: verify multi-class entity validation for NHI combinations#1202

Closed
jmountifield wants to merge 2 commits into
mainfrom
AIASM-14/multi-class-nhi-validation
Closed

AIASM-14: verify multi-class entity validation for NHI combinations#1202
jmountifield wants to merge 2 commits into
mainfrom
AIASM-14/multi-class-nhi-validation

Conversation

@jmountifield
Copy link
Copy Markdown

What

Verification-only PR pinning the SDK's existing multi-class behavior with NHI as
a secondary class. No source changes — adds 3 test files (+501 lines) covering
the BDD scenarios from AIASM-14.

Scenario Test
14.1 — User+NHI validates against both class schemas createIntegrationHelpers.test.ts (helper + EntityValidator), createIntegrationEntity.test.ts
14.2 — AccessKey+NHI variant createIntegrationEntity.test.ts, createIntegrationHelpers.test.ts
14.3 — createMultiClassEntityMetadata works with NHI createIntegrationHelpers.test.ts (User+NHI and AccessKey+NHI helpers, validating the produced JSON Schema)
14.4 — toMatchDataModelSchema validates NHI multi-class jest.test.ts (testing pkg)
14.5 — NHI properties whitelisted across multi-class entities createIntegrationEntity.test.ts (schemaWhitelistedPropertyNames test.each over User, AccessKey, Application, Certificate, Secret × NHI; plus createIntegrationEntity preservation tests for each combo)

Why

schemaWhitelistedPropertyNames already unions properties across all classes in
_class[], and createMultiClassEntityMetadata already builds an allOf JSON
Schema with $refs to each class. The deliverable per the ticket's
implementation notes is "a test suite proving it" — this is that suite.

Notes

  • NHI is registered inline via dataModel.IntegrationSchema.addSchema() in each
    test, because @jupiterone/data-model@0.62.0 does not yet ship NHI.
    Publishing is AIASM-15.
  • For the testing-package matcher test, NHI must be registered with both the
    dataModel singleton and the getValidatorSync() validator instance so the
    $ref resolves and the validator can compile.
  • User-class required fields (firstName, lastName, email[], …) are rigid
    for service accounts in the wild — flagged in test comments as a data-model
    concern outside AIASM-14 scope.
  • This branch is independent of AIASM-13: permissive enum warnings for NHI metadata properties #1201 (AIASM-13). They can land in either order.

Test plan

  • integration-sdk-core jest 144/144 green
  • integration-sdk-testing jest 105/105 green
  • tsc --noEmit clean across both packages
  • Pre-push: full lerna build + lint + 91 changed-suite tests green

🤖 Generated with Claude Code

Pin the SDK's existing multi-class behavior with NHI as a secondary class.
Covers AIASM-14 BDD scenarios:

- 14.1/14.2 — User+NHI and AccessKey+NHI multi-class entities created via
  createIntegrationEntity preserve both primary-class properties (username,
  fingerprint, etc.) and NHI metadata (_nhiType, _isAi, …).
- 14.3 — createMultiClassEntityMetadata accepts an NHI typebox alongside
  typeboxClassSchemaMap entries, produces a JSON schema with $refs to both
  classes, and the resulting createEntity output validates cleanly.
- 14.4 — toMatchDataModelSchema passes for a User+NHI entity when the NHI
  schema is registered with the validator singleton.
- 14.5 — schemaWhitelistedPropertyNames unions properties across all classes
  in the array, including the NHI metadata set, for the five combinations
  called out in the implementation notes (User, AccessKey, Application,
  Certificate, Secret + NHI).

NHI is registered inline in each test file because @jupiterone/data-model
0.62.0 does not yet ship NHI; publishing the schema is AIASM-15.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@jmountifield jmountifield requested a review from a team as a code owner April 29, 2026 13:30
…Entity owner

Tracks data-model PR #104 review:

- Inline NHI schemas in all three test files now use bare property
  names (nhiType, isAi, aiConfidence, aiPlatform, nhiOwnerStatus)
  matching the data-model NHI.json convention. Underscore prefix
  is reserved for system-managed fields (_class, _type, _key).

- Drop the _nhiOwner property entirely. The data-model schema redeclares
  Entity's existing `owner` field with an NHI-specific description
  rather than introducing a separate property — the inline test
  fixtures now match that shape.

- Update test data and assertions accordingly. NHI_PROPERTIES whitelist
  array drops _nhiOwner.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@jmountifield
Copy link
Copy Markdown
Author

jmountifield commented Apr 30, 2026

Closing — see AIASM-14 for rationale. The verification work confirmed the SDK already supports multi-class _class: ['User', 'NHI'] (etc.) without any code changes. With AIASM-15 closed (live service is now the runtime source of truth for NHI), the regression-test value here has reduced.

The branch AIASM-14/multi-class-nhi-validation is preserved on origin if regression coverage is wanted later.

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