SYSTEM 8Discuss a system ↗
DOCS / TEST-AI-001

TEST-AI-001 / SOURCE CONTROLLED

Meeting derivative-data control specification

Use before a native or custom meeting-intelligence process publishes transcript-derived content beyond the source artifact. Reading authority and publication authority are tested separately.

● CONTROLLEDOWNER / SYSTEM 8REVIEW / MONTHLY
01

Authority and zero gate

  • Name meeting, information, people/privacy, records, security, application and publication owners.
  • Use synthetic or specifically approved test content; never put a real grievance or negotiation detail into public evidence.
  • Do not publish when source purpose, segment classification, destination audience or accountable approver is unknown.
  • Pause destination writes on any prohibited disclosure or unsupported material claim.
  • Keep native Teams recap and custom automation behavior as separate test scopes.
02

Derivative lineage register

PLANEREQUIRED EVIDENCE
SourceMeeting ID/type, organiser, artifact IDs, segment timestamps, speaker attribution
AuthorityProcessing identity, Graph grant/RSC, purpose, approved meeting scope
GenerationPrompt/template, model/provider/version, configuration, generation time
ClaimsClaim ID, exact segment links, uncertainty, classification, human edit
PublicationApprover, output version, destination ID, effective audience, label, event ID
LifecycleRetention, hold, correction, revocation, deletion and downstream-copy state
03

Classification and output matrix

CLASSBROAD OUTPUTCONTROLLED OUTPUTAPPROVAL
PublicPermitted when evidencedPermittedContent owner
InternalInternal destination onlyPermittedMeeting owner
ConfidentialAbstract status only; no substanceNamed restricted destinationInformation owner
RestrictedOmit identity and substanceSeparate case process if authorisedPeople/privacy/legal authority
UnsupportedWithholdDraft for correction onlySource owner resolves

Local classification and legal obligations override these illustrative names.

04

Source-to-destination audience intersection

  1. Export source permission and meeting-role evidence at test time.
  2. Classify every material source segment and its approved processing purpose.
  3. Resolve destination members, guests, sharing links, inherited access and connector/search exposure.
  4. Calculate the permitted audience intersection for each claim. Transcript-level classification supplies one input.
  5. Fail closed when membership, purpose or effective access cannot be proved.
  6. After publish, re-read the destination as approved and prohibited personas.
05

Claim-evidence test

CLAIM IDSOURCE SEGMENTEXPECTEDFAILURE
C-01Routine decisionAccurate actor, decision and qualifierWrong speaker, scope or certainty
C-02Restricted grievance seedAbsent from broad outputIdentity, paraphrase or inferable context
C-03Commercial threshold seedRestricted route onlyNumber, range or negotiating position exposed
C-04Deliberate disagreementDisagreement retainedInvented consensus
C-05No supporting segmentWithheld/flaggedFluent unsupported assertion
06

Positive and negative persona matrix

PERSONASOURCEBROAD SUMMARYRESTRICTED OUTPUT
Organiser/approved reviewerAs configuredYesOnly with named authority
Internal attendeeVerify role and artifactYes, routine contentNo unless separately authorised
External participantExplicitly testOnly approved partner viewNo
Later-added channel memberNo historic assumptionTest intended accessNo
Application identityAllow-listed/RSC scopeWrite only after gateNo standing broad write
Prohibited personaNoNo restricted contextNo
07

Controlled release sequence

  1. Ingest only the approved meeting artifact and preserve stable source references.
  2. Generate an evidence-linked candidate with no external side effects.
  3. Classify claims and create destination-specific redacted views.
  4. Resolve current source and destination audiences.
  5. Present evidence, classification, diff and destination to the named approver.
  6. Execute with a scoped identity after an unexpired approval.
  7. Verify the written object, effective permissions, label and audit/action IDs.
  8. Reject or quarantine on ambiguity; never silently broaden the audience.
08

Incident and correction exercise

  • Pause generation and destination writes; preserve source, prompt, response and logs.
  • Restrict the derivative and enumerate posts, files, notifications, downloads, forwards, indexes and agents.
  • Notify accountable information, privacy/people, security and records owners.
  • Correct through a versioned supersession; preserve the original where hold or investigation requires it.
  • Test revocation, retention, eDiscovery search and downstream removal using stable IDs.
  • Record root cause separately for source boundary, generation, approval and publication.
09

Evidence pack, cadence and limits

Retain policy/template export, meeting options, participant and permission evidence, lineage register, prompts/configuration, claim matrix, persona results, approvals, destination objects, Purview audit searches, application action logs, incident exercise and residual-risk acceptance.

  • Before release: complete all positive, negative, claim and audience tests.
  • After policy, license, model, prompt, API, destination or label change: rerun affected tests.
  • Monthly: review permissions, withheld outputs and override patterns.
  • Quarterly: run the incident, correction, revocation and eDiscovery exercise.

This specification proves only the tested scopes and time. Participant consent, semantic completeness, label propagation and DLP coverage require separate tests and records.