Skip to main content
There are two ways to fit your catalog to a person. Ranking on the device needs nothing new from them. Ranking on your server needs a summary to leave the phone, so it has its own permission.

On the device

Hand PoolKit the items you are about to show, such as a catalog page or a starter grid. They come back in the order that fits what the person saved.
  • A candidate is your id plus whatever you have: text, imageData (PNG, JPEG or HEIC), or an embedding you computed yourself. Up to 500 candidates per call.
  • Only your ids, scores and reasons come back. No photo, no capture id and no library content.
  • It needs the query operation, like any other read.
A score orders the candidates of one call. It is not a probability and not a measure you can compare across people. Unlike classify, rank scores are not fitted to labelled data in this version.

On your server

To search a large catalog, ask for a summary of the person’s visual taste and run the search yourself.
  • centres holds six vectors by default, each with a weight. The weights sum to 1. Pass clusters: for 1 to 12.
  • They are centres of groups of captures, never a vector for one capture, and nothing in them points back to a photo.
  • modelSignature names the model the vectors come from. Embed your catalog with the same model, and check the signature before you mix vectors from two calls.
  • With fewer than 20 saved captures there are no centres, and basedOnCaptures says how many there were.
  • Captures that Pool marks as sensitive never take part.
exportTaste is a separate operation because these vectors leave the device. Say so in the purpose you show the person. A grant without it makes tasteVectors fail with PoolError.operationNotGranted.

What ranking never says

PoolKit orders your items and exports vectors. It never states that a person likes something, and it has no labels for mood, style or personality.