diff --git a/tables.sql b/tables.sql
index fffc64e..10b1a1f 100644
--- a/tables.sql
+++ b/tables.sql
@@ -100,12 +100,16 @@ insert into FACE_OVERRIDE_TYPE values ( (select nextval('FACE_OVERRIDE_TYPE_ID_S
 insert into FACE_OVERRIDE_TYPE values ( (select nextval('FACE_OVERRIDE_TYPE_ID_SEQ')), 'Ignore face' );
 insert into FACE_OVERRIDE_TYPE values ( (select nextval('FACE_OVERRIDE_TYPE_ID_SEQ')), 'Manual match' );
 
-create table FACE_NO_MATCH_OVERRIDE ( ID integer, FACE_ID integer, TYPE integer, 
+-- keep non-redundant FACE because, when we rebuild data we may have a null FACE_ID, but still want to connect to this override
+-- from a previous AI pass... (would happen if we delete a file and then reimport/scan it), OR, more likely we change (say) a threshold, etc.
+-- any reordering of faces, generates new face_ids... (but if the face data was the same, then this override should stand)
+create table FACE_NO_MATCH_OVERRIDE ( ID integer, FACE_ID integer, TYPE integer, FACE bytea,
     constraint FK_FNMO_FACE_ID foreign key (FACE_ID) references FACE(ID),
     constraint FK_FNMO_TYPE foreign key (TYPE) references FACE_OVERRIDE_TYPE(ID),
     constraint PK_FNMO_ID primary key(ID) );
--- this could really suck, maybe we dont allow this???
---create table FACE_MANUAL_OVERRIDE ( ID integer, FACE_ID integer, PERSON_ID integer, TYPE integer, constraint PK_FACE_MANUAL_OVERRIDE_ID primary key(ID) );
+
+-- manual match goes to person not refimg, so on search, etc. we deal with this anomaly (via sql not ORM)
+create table FACE_MANUAL_OVERRIDE ( ID integer, FACE_ID integer, PERSON_ID integer, TYPE integer, constraint PK_FACE_MANUAL_OVERRIDE_ID primary key(ID) );
 
 create table PERSON_REFIMG_LINK ( PERSON_ID integer, REFIMG_ID integer,
     constraint PK_PRL primary key(PERSON_ID, REFIMG_ID),